DOCSLIB.ORG

Performance Testing Modeling: an Empirical Evaluation of DSL and UML-Based Approaches

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Performance Testing Modeling: an empirical evaluation of DSL and UML-based approaches Maicon Bernardino Elder M. Rodrigues Avelino F. Zorzo PUCRS PUCRS PUCRS Av. Ipiranga, 6681, Partenon Av. Ipiranga, 6681, Partenon Av. Ipiranga, 6681, Partenon Porto Alegre, RS, Brazil Porto Alegre, RS, Brazil Porto Alegre, RS, Brazil [email protected] [email protected] [email protected] ABSTRACT software testing [8], e.g. unit testing, functional testing and Performance testing modeling is a relative new research field. performance testing. However, software testing is a time Researches investigating how to apply models to document consuming and highly specialized phase in a software devel- performance testing information essentially started to be opment process. For instance, for a company to apply per- reported in the last decade. Motivated by the lack of a formance testing [6], it requires a team of performance engi- standard to represent performance testing information, our neers and testers with deep knowledge about the application research group, in collaboration with an IT company, pro- to be tested, its usage profile, and the infrastructure where posed a UML approach and lately a Domain-Specific Lan- it will operate. Moreover, it will also require a performance guage (DSL) to support performance testing modeling. The engineer with great ability on identifying and tracing appli- goal of this paper is to show how we support our partner cations requirements to performance requirements. Another company on the decision process to replace UML by a DSL, issue faced by performance testing teams is that most com- hence we designed and conducted an experimental study to panies still write applications requirements in an ambiguous provide evidence about the benefits and drawbacks when us- textual format, which could lead to misinterpretation and ing UML or DSL for modeling performance testing. In this inconsistencies on the definition of the performance require- paper, we report an in vitro experiment, where the subjects ments. Moreover, the lack of an unambiguous standard to designed UML models and DSL models, for the purpose of write the performance test case is another issue to be tackled evaluation with respect to the effort and suitability, from in performance testing. the perspective of the performance testers and the perfor- In order to mitigate these issues and to improve the com- mance engineers in the context of industry and academia munication between development and testing teams, our re- for modeling performance testing. Our results indicate that, search group proposed a model-based approach, based on for performance modeling, effort using a DSL was lower than a UML profile, to support the performance testing mod- eling [11]. After an empirical investigation [13], a partner using UML. Our statistical analysis showed that the results 1 were valid, i.e., that to design performance testing models company started the adoption of our approach, allowing using our DSL is better than using UML. performance teams to get involved in designing test models from early stages of the software development process and supporting the automatic generation of the performance ar- CCS Concepts tifacts from the applications models. Despite all the ben- •Software and its engineering ! Software perfor- efits, our daily experience on using UML models to design mance; Domain specific languages; •General and ref- performance testing revealed that it presents some limita- erence ! Experimentation; tions [2]: (a) most of available UML design tools do not pro- vide support to work with only those UML elements that are Keywords needed for a specialized language. Thus, the presence of un- used and not required elements may result in an error-prone Experiment; performance testing; domain-specific language and complex activity; (b) UML diagrams are restricted to the semantics that is defined by Object Management Group 1. INTRODUCTION (OMG) [9]. Therefore, in some cases, the available UML el- Nowadays, software quality has become a very important ements and their semantics can restrict or even prevent the asset, even for medium/small software development compa- modeling of some performance features for the Web domain. nies. In most of these companies, software quality rely on To overcome these issues, we have proposed and imple- mented a Domain-Specific Language (DSL) [5] to the per- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed formance domain: Canopus [2]. Canopus provides a graph- for profit or commercial advantage and that copies bear this notice and the full citation ical and textual DSL to support the design of performance on the first page. Copyrights for components of this work owned by others than the models. Our DSL, unlike the UML Testing profile, is de- author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission signed to support the performance testing modeling activity and/or a fee. Request permissions from [email protected]. and also to be used within MBT tools to generate perfor- SAC 2016, April 04 - 08, 2016, Pisa, Italy mance test scripts and scenarios for third-party tools/load Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-3739-7/16/04. $15.00 1Study developed in the context of PDTI 001/2015, financed DOI: http://dx.doi.org/10.1145/2851613.2851832 by Dell Computers with resources of Law 8.248/91. 1660 generators. It is important to notice that our DSL was de- 3. EXPERIMENT INSTRUMENTS signed and developed based on our previous experience and In this section we briefly present the UML approach for on our partner's expertise on performance testing model- modeling performance testing, the Canopus, and LimeSur- ing and on applying model-based testing to generate per- vey and Moodle 2 used as Systems Under Test (SUT) during formance scripts and scenarios. Despite all our expertise on the experiment training and execution: (a) UML pro- performance testing modeling, there was a lack of knowledge file for performance testing [11]: allows the use of UML about the benefits and drawbacks of using DSL or UML to Use Case and Activity diagrams annotated with stereotypes design performance testing model. Motivated by this lack and tagged values to model performance testing. Our ap- of knowledge, we planned and conducted an experimental proach to model performance information into UML mod- study to provide evidence about the benefits and drawbacks els relies on stereotypes3 to annotate test scenario informa- when using UML or DSL for modeling performance testing. tion into Use Case diagrams and the test case information These evidences will support our partner company on the de- into Activity diagrams; (b) Canopus: aims to allow per- cision process on the replacement of UML by Canopus. We formance testing teams to model the activities performed understand that some of the limitations, mentioned above, by the application's users and the environment where the are due to UML being a general propose language, but to applications is hosted. Canopus is composed of three meta- the best of our knowledge, there is no work that show that models: performance monitoring, performance scenario and UML performs better, in performance testing, than a DSL. performance scripting. The performance monitoring meta- This paper is organized as follows. Section 2 presents some model supports the design of a model to represent the test- context relative to the company in place, as well as motiva- ing environment infra-structure, such as application servers, tions for the study. Section 3 introduces the experiment database servers, and the load generator servers. This meta- instruments. Section 4 presents the experiment design and model supports the definition of performance counters that introduces our research questions. Section 5 describes the will be monitored during the test execution, for every server. execution of the experiment, while Section 6 presents our The performance scenario metamodel supports the model- analysis and interpretation of results. Finally, we present ing of the users workload profiles and the probabilities of the conclusion and future work. execution of test cases by each of these profiles. For every modeled workload profile, it must be instantiated to a per- 2. EXPERIMENT CONTEXT formance workload metamodel.4.A performance scripting In the past years our research group in performance test- metamodel is used to model the virtual users behavior, and ing has been investigating, in cooperation with a Technology it must be bound to a user profile; (c) LimeSurvey: is Development Lab (TDL) of a global IT company, novel ap- an open source Web application that allows non-technical proaches and strategies to support performance testing. One users to quickly create on-line question-and-answer surveys; of our main research focus is the automation of performance (d) Moodle: is an open source learning management plat- testing process, mainly through the application of Model- form that provides a customized virtual environment for ed- based Testing (MBT) [15] approaches and its related lan- ucators and students. guages and modeling notations. In this context, we have pro- posed and empirically evaluated several approaches [12] [13], 4. EXPERIMENT DESIGN notations [4] [14], languages [2] and tools
Recommended publications
  • Activity Diagram Inheritance1

    Activity Diagram Inheritance1

    Activity Diagram Inheritance1 Arnd Schnieders, Frank Puhlmann Hasso-Plattner-Institute for IT Systems Engineering at the University of Potsdam {schnieders, puhlmann}@hpi.uni-potsdam.de Abstract This paper outlines the ongoing work on the realization of a flexible inheritance mechanism for Activity Diagrams that assures the maintenance of syntactical correctness for the derived Activity Diagrams. The objective is to support the reuse of process models especially by applying Activity Diagram inheritance as a variability mechanism in the context of product line oriented software development. Keywords: Activity Diagrams, domain engineering, process inheritance, variability mechanism 1. Introduction In industry similar products are frequently developed and produced as product lines. One of the main advantages is a gain of efficiency in development and production since parts, which are common for several product line members, can be reused optimally. This approach has been transferred successfully to software development and is also known by the name domain engineering. Variability mechanisms are thereby important for the effectiveness of domain engineering. A great number of variability mechanisms has already been published [5, 9, 11, 13, 18]. Unfortunately, existing variability mechanisms only refer to the static aspects of a software system’s design while the impact of variability mechanisms on the process view on the system has been strongly neglected. Therefore, the first contribution of this paper is to contribute to closing this gap by making the important variability mechanism inheritance available for process design models in order to derive process model variants. The second contribution of this paper is to show how the defined process inheritance mechanism is realized concretely for UML 2.0 Activity Diagrams.
  • Lecture for Chapter 2, Modeling With

    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.
  • 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.
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007

    OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007

    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
  • How to Build a UML Model Announcements Rational Unified

    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
  • 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
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language

    Sysml Distilled: a Brief Guide to the Systems Modeling Language

    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
  • Sysml Activity Diagram Some Basic Semantics Theodore.Kahn@Engility.Com

    Sysml Activity Diagram Some Basic Semantics [email protected]

    SysML Activity Diagram Some Basic Semantics [email protected] 1. Does this diagram follow all SysML rules, is it semantically correct? 2. If it is correct, is it good SysML, is the modeler’s intent clear? 3. What is the modeler’s intent? The semantics discussed are not comprehensive; rather, they are meant to cover only some of the most common usages. Readers are encouraged to consult additional documentation to obtain a fuller understanding of the SysML grammar. Activity Edges Control and Object Flows Control Flow Object Flow The most basic function of Activity Diagrams is the Object flow Pin. Control flow activity edge, commutation of information activity edge, solid line. among Actions. This is dashed line. accomplished by using either or both types of activity edges, as required: Best Practices 1. Use Object Flows whenever possible as they explicitly specify what is being communicated between Actions. 2. The two object flow constructs on the right are semantically identical. In general, the use of pins is preferred as it is more concise and allows for typecasting, should that be required. Activity Edge Semantics 1. An Action cannot start until all Control and Object tokens are received at the Action edge. 2. When an Action finishes, it provides all Control and Object tokens to their respective flows. Diagram Flow Discussion 1. When A finishes, it provides The Activity Diagram on the Control tokens to B and C at the left is grammatically correct. same time. However, the Control Flow 2. B then starts. When B finishes, it between A and B is provides a Control token to C.
  • The Validation Possibility of Topological Functioning Model Using the Cameo Simulation Toolkit

    The Validation Possibility of Topological Functioning Model Using the Cameo Simulation Toolkit

    The Validation Possibility of Topological Functioning Model using the Cameo Simulation Toolkit Viktoria Ovchinnikova and Erika Nazaruka Department of Applied Computer Science, Riga Technical University, Setas Street 1, Riga, Latvia Keywords: Topological Functioning Model, Execution Model, Foundational UML, UML Activity Diagram. Abstract: According to requirements provided by customers, the description of to-be functionality of software systems needs to be provided at the beginning of the software development process. Documentation and functionality of this system can be displayed as the Topological Functioning Model (TFM) in the form of a graph. The TFM must be correctly and traceably validated, according to customer’s requirements and verified, according to TFM construction rules. It is necessary for avoidance of mistakes in the early stage of development. Mistakes are a risk that can bring losses of resources or financial problems. The hypothesis of this research is that the TFM can be validated during this simulation of execution of the UML activity diagram. Cameo Simulation Toolkit from NoMagic is used to supplement UML activity diagram with execution and allows to simulate this execution, providing validation and verification of the diagram. In this research an example of TFM is created from the software system description. The obtained TFM is manually transformed to the UML activity diagram. The execution of actions of UML activity diagrams was manually implemented which allows the automatic simulation of the model. It helps to follow the traceability of objects and check the correctness of relationships between actions. 1 INTRODUCTION It represents the full scenario of system functionality and its relationships. Development of the software system is a complex The simulation of models can help to see some and stepwise process.
  • UML Notation Guide

    UML Notation Guide

    UML Notation Guide version 1.1 1 September 1997 Rational Software ■ Microsoft ■ Hewlett-Packard ■ Oracle Sterling Software ■ MCI Systemhouse ■ Unisys ■ ICON Computing IntelliCorp ■ i-Logix ■ IBM ■ ObjecTime ■ Platinum Technology ■ Ptech Taskon ■ Reich Technologies ■ Softeam ad/97-08-05 Copyright © 1997 Rational Software Corporation Copyright © 1997 Microsoft Corporation Copyright © 1997 Hewlett-Packard Company. Copyright © 1997 Oracle Corporation. Copyright © 1997 Sterling Software. Copyright © 1997 MCI Systemhouse Corporation. Copyright © 1997 Unisys Corporation. Copyright © 1997 ICON Computing. Copyright © 1997 IntelliCorp. Copyright © 1997 i-Logix. Copyright © 1997 IBM Corporation. Copyright © 1997 ObjecTime Limited. Copyright © 1997 Platinum Technology Inc. Copyright © 1997 Ptech Inc. Copyright © 1997 Taskon A/S. Copyright © 1997 Reich Technologies Copyright © 1997 Softeam Photocopying, electronic distribution, or foreign-language translation of this document is permitted, provided this document is reproduced in its entirety and accompanied with this entire notice, including the following statement: The most recent updates on the Unified Modeling Language are available via the worldwide web: http://www.rational.com/uml The UML logo is a trademark of Rational Software Corporation. Contents 1. DOCUMENT OVERVIEW 1 2. DIAGRAM ELEMENTS 3 2.1 Graphs and their Contents . 3 2.2 Drawing paths . 4 2.3 Invisible Hyperlinks And The Role Of Tools . 4 2.4 Background information . 4 2.5 String . 5 2.6 Name . 6 2.7 Label . 7 2.8 Keywords. 8 2.9 Expression . 8 2.10 Note . 10 2.11 Type-Instance Correspondence . 11 3. MODEL MANAGEMENT 13 3.1 Packages and Model Organization . 13 4. GENERAL EXTENSION MECHANISMS 16 4.1 Constraint and Comment . 16 4.2 Element Properties.
  • Lab 002 – Use Case Modeling.Pdf

    Lab 002 – Use Case Modeling.Pdf

    TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia LAB 2: Introduction to Use Case Modeling OBJECTIVES Familiarize with the concept underlining Use Case Diagram for requirement analysis. Exposure on all elements grouped under UML Case Diagram. Analyze functional requirements and problem statements of an intended system to be able to translate into use case modeling. Be able to document use case description and specifications. INTRODUCTION Definition of Use Case Diagram A Use Case is a set of scenarios describing an interaction between a user and a system. Use Case diagram displays (in symbolic form) the relationship among actor and use cases. Use case represents the system’s functionality, the requirements of the system from the user’s perspective. When to use Use Cases Use cases are used in almost every project. Very helpful in exposing requirements and planning of project. Usually done during the early stages of project. Frequently starts by being loose in terms of connection and accuracy, but as project continues, the use cases are defined better. UML Notation for Use Case Modeling Construct Description Syntax Use Case A description of a set of sequences of actions, including variants, that system performs that yields an observable value to an actor (Booch, 1993). Actor The people or system that provides or receives information from the system; called the stakeholder of the system. Nor Samsiah Binti Sani 1 TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia System The boundary between the physical system and Boundary the actors who interact with the physical system.
  • State and Activity Diagrams in UML Last Revised December 4, 2018 Objectives: 1

    State and Activity Diagrams in UML Last Revised December 4, 2018 Objectives: 1

    CPS122 Lecture: State and Activity Diagrams in UML last revised December 4, 2018 Objectives: 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Answers to quick check questions from chapter 7 plus chapter 8 a, b, g 2. Demonstration of “Racers” program 3. Handout and Projectable on Web: State diagram for Session 4. Handout: Code for Session class performSession() method 5. Projectable of text figures 7.12, 7.13 6. Handout of Activity diagram for Racers 7. Projectable of text figure 8.10 I. Introduction A.Go over quick check questions chapter 7 + chapter 8 a, b, g only B. We have drawn a distinction between the static aspects of a system and its dynamic aspects. The static aspects of a system have to do with its component parts and how they are related to one another; the dynamic aspects of a system have to do with how the components interact with one another and/or change state internally over time. C. We have been looking at one aspect of the dynamic behavior of a system - the way various objects interact to carry out the various use cases. We have looked at two ways of describing this: 1. Sequence diagrams 2. Communication diagrams D.We now want to look two additional aspects of dynamic behavior !1 1. How an individual object changes state internally over time. a) Example: As part of doing the domain analysis of a traffic light system, it is important to note that individual signals go through a series of states in a prescribed order - modeled by the following state diagram: ! (Note: this is correct for the US but not for all countries in the world!) An important “business rule” that any traffic light system must obey is that the light must be yellow for a certain minimum period of time (related to vehicle speed in the intersection) between displaying green and displaying red.