DOCSLIB.ORG

A Design Discipline and Language Features for Modular Reasoning in Aspect-Oriented Programs Curtis Charles Clifton Iowa State University

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2005 A design discipline and language features for modular reasoning in aspect-oriented programs Curtis Charles Clifton Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Clifton, Curtis Charles, "A design discipline and language features for modular reasoning in aspect-oriented programs " (2005). Retrospective Theses and Dissertations. 1840. https://lib.dr.iastate.edu/rtd/1840 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. A design discipline and language features for modular reasoning in aspect-oriented programs by Curtis Charles Clifton A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee: Gary T. Leavens, Major Professor lien Morris Chang Markus Lumpe Robyn R. Lutz lonathan D. H. Smith Iowa State University Ames, Iowa 2005 Copyright © Curtis Charles Clifton, 2005. All rights reserved. UMI Number: 3184594 INFORMATION TO USERS The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleed-through, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. UMI UMI Microform 3184594 Copyright 2005 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, Ml 48106-1346 ii Graduate College Iowa State University This is to certify that the doctoral dissertation of Curtis Charles Clifton has met the dissertation requirements of Iowa State University Signature was redacted for privacy. or Professor Signature was redacted for privacy. For the Major Program iii To Pastor Daniel Solomon, a model of perseverance and faithful dedication, and a good friend iv TABLE OF CONTENTS LIST OF TABLES viii LIST OF FIGURES ix ACKNOWLEDGMENTS xii ABSTRACT xiv CHAPTER 1. INTRODUCTION 1 1.1 Aspect-oriented Programming 2 1.2 Practical Benefits 4 1.2.1 Applications of Aspect-Oriented Features 4 1.3 Theoretical Challenges 6 1.3.1 Object-Oriented Non-modularity 7 1.3.2 Behavioral Subtyping 8 1.3.3 Non-modularity in Aspect-Oriented Languages 9 1.3.4 Modular Aspect-oriented Reasoning 10 1.4 Scope 11 1.5 Statement of the Thesis 12 CHAPTER 2. THE MAO DISCIPLINE 13 2.1 The Discipline 14 2.2 Proposed Language Features 15 2.2.1 Assistants 15 2.2.2 Spectators 23 2.3 Evaluation 26 2.3.1 ATLAS Case Study 26 2.3.2 Impact of Restrictions 27 2.3.3 Summary of Evaluation 33 V 2.4 Specification and Reasoning 33 2.4.1 Specifying Around Advice 34 2.4.2 Specification Composition 39 2.5 Discussion 54 2.5.1 Language Issues 54 2.5.2 Specification Issues 57 2.5.3 Tool Support 57 2.6 Related Work 58 2.7 Conclusion 62 CHAPTERS. MINIMAOi : INVESTIGATING THE SEMANTICS OF PROCEED 64 3.1 MiniMAOo: A Core Object-Oriented Calculus with Classes 64 3.1.1 Syntax of MiniMAOo 65 3.1.2 Operational Semantics of MiniMAOo 66 3.1.3 Static Semantics of MiniMAOo 75 3.1.4 Meta-theory of MiniMAOo 78 3.2 MiniMAOi : Adding Aspects 88 3.2.1 Syntax of MiniMAOi 89 3.2.2 Operational Semantics of MiniMAOi 91 3.2.3 Static Semantics of MiniMAOi 112 3.2.4 Meta-theory of MiniMAOi 117 3.3 Related Work 144 3.4 Discussion 146 3.5 Conclusion 147 CHAPTER 4. MINIMA02: PARTITIONING THE HEAP BY CROSS-CUTTING CONCERNS 149 4.1 Intuition 150 4.2 Syntax 152 4.2.1 Public Concern Domain Declarations 153 4.2.2 Class and Aspect Instantiation 153 4.2.3 Refined Types 157 4.2.4 Effects Clauses 158 4.2.5 New Pointcut Descriptor 158 4.2.6 Concern Domain Dependencies 158 vi 4.3 Semantics 159 4.3.1 Operational Semantics 159 4.3.2 Static Semantics 169 4.4 Meta-theory 184 4.4.1 Auxiliary Definitions and Lemmas 185 4.4.2 Type Safety 217 4.4.3 Effects Properties 231 4.5 Related Work 242 4.6 Conclusion 247 CHAPTER 5. MiniMA03: SPECTATORS REALIZED 249 5.1 Differences Versus MiniMAOg 249 5.1.1 Syntax of MiniMAOg 250 5.1.2 Operational Semantics of MiniMAOs 252 5.1.3 Static Semantics of MiniMAOa 257 5.2 Meta-Theory of MiniMAOg 263 5.2.1 Supporting Definitions and Lemmas 264 5.2.2 Type Safety 273 5.2.3 Effects 280 5.3 Discussion 288 5.4 Related Work 288 5.5 Conclusion 289 CHAPTER 6. CONCLUSIONS AND FUTURE WORK 290 6.1 Support for the Thesis 290 6.2 Open Problems 292 6.2.1 Verification 292 6.2.2 MAO 295 6.3 Future Work 298 6.3.1 Alias Control 298 6.3.2 Late Binding and Aspect-Oriented Virtual Machines 298 6.3.3 Concurrent Aspect-oriented Programming 299 6.3.4 Subtype Matching in Around? Unsound! 299 6.3.5 Component-based Programming 301 6.4 Postscript BIBLIOGRAPHY viii LIST OF TABLES 2.1 Categorization of Examples from the Aspect] Programming Guide 28 2.2 Categorization of Examples from Kiselev's Text 30 4.1 Reach and Writable Reach for the Store, S, of Figure 4.24 235 ix LIST OF FIGURES 1.1 Point Class 7 1.2 Sample Client Code 8 1.3 RightMovingPoint Class 8 1.4 O neWay Mov i rig Aspect 9 2.1 FigureElement Example (in Java with JML annotations) 16 2.2 MoveLimiting Example (in AspectJ) 17 2.3 Syntax of Concern Maps 21 2.4 Example Concern Map 21 2.5 Example Spectator Aspect 24 2.6 Example of JML Specification Cases 35 2.7 Example JML Specification Showing Overlapping Specification Cases 36 2.8 Around Advice Specification in AspectJML 37 2.9 Example Specification for Around Advice with Multiple proceed Expressions 38 2.10 Specification Composition Graph Construction, Stage Go 42 2.11 Specification Composition Graph Construction, Partially Complete Stage Gi 43 2.12 Specification Composition Graph Construction, Stage Gi 44 2.13 Unique Path through Specification Composition Graph, «-converted 46 2.14 General Form of the Effective Specification 51 2.15 Effective Specification for the Path Shown in Figure 2.13 53 2.16 Simplified Version of Effective Specification from Figure 2.15 54 2.17 Effective Specification Derived from the Specification Composition Graph in Figure 2.12 54 3.1 Syntax of MiniMAOo 65 3.2 Operational Semantics of MiniMAOo 67 3.3 Auxiliary Functions for MiniMAOo 70 X 3.4 Subtyping in MiniMAOo 71 3.5 Sample MiniMAOo Program 72 3.6 Static Semantics of MiniMAOo 76 3.7 Syntax Extensions for MiniMAOi 90 3.8 Join Point Stack 92 3.9 Additional Expression Forms for the Operational Semantics of MiniMAOi 93 3.10 Changes to the Operational Semantics for MiniMAOi 95 3.11 Additional Subtyping Rule for MiniMAOi 96 3.12 Auxiliary Functions for MiniMAOi Operational Semantics 97 3.13 Boolean Algebra over Binding Terms 101 3.14 Pointcut Descriptor Matching for MiniMAOi 102 3.15 Comparison of Evaluation in MiniMAOo and MiniMAOi 105 3.16 Sample Program Showing Advice Binding 106 3.17 Sample Derivation of Pointcut Descriptor Matching 107 3.18 Sample Program Showing Advice Chaining 108 3.19 Sample Program Contrasting this vs. target Binding and call vs. execution Advice .... 110 3.20 Additions to the Static Semantics for MiniMAOi 113 3.21 Binding for Type Environments 115 3.22 Static Semantics of Pointcuts in MiniMAOi 116 3.23 Meta-variables Used in the Proof of Lemma 3.15 122 4.1 Schematic View of a Store in MiniMAOg 151 4.2 Syntax of MiniMAO^ 154 4.3 Fragment of a MiniMAOi Program Illustrating New Syntax 155 4.4 Syntax Extensions for the Operational Semantics of MiniMA02 160 4.5 Join Point Stack in MiniMAO^ 161 4.6 Example of Advice Table Construction 162 4.7 Evaluation Relation for the Operational Semantics of MiniMA02 164 4.8 Evaluation Relation for the Operational Semantics of MiniMA02 (Exceptional Rules) ..165 4.9 Auxiliary Functions for Operational Semantics of MiniMA02 167 4.10 More Auxiliary Functions for MiniMA02 Operational Semantics 168 4.11 Subtyping in MMMAO2 169 4.12 Pointcut Descriptor Matching for MiniMAOa 170 xi 4.13 Bindings in MiniMA02 171 4.14 Static Semantics of Declarations in MiniMA02 174 4.15 Auxiliary Functions for Static Semantics of MiniMA02 176 4.16 Auxiliary Typing Judgments for Declarations in MiniMA02 176 4.17 Static Semantics of Expressions in MiniMA02 179 4.18 Sample Expression Type Errors in MiniMAÛ2 180 4.19 Binding for Type Environments 182 4.20 Static Semantics of Pointcuts in MiniMAÛ2 183 4.21 Venn Diagram Illustrating Lemma 4.6 187 4.22 Setup and Common Meta-variable Bindings Used in the Proof of Lemma 4.14 200 4.23 Auxiliary Functions for the Meta-theory of MiniMA02 234 4.24 Schematic View of a Sample Store, S 235 4.25 Recursive Definition of the Locations Included in an Expression 236 5.1 Differences in Syntax of MiniMAOg vs.
Recommended publications
  • Object-Oriented Programming in Scheme with First-Class Modules

    Object-Oriented Programming in Scheme with First-Class Modules

    Ob jectOriented Programming in Scheme with FirstClass Mo dules and Op eratorBased Inheritance Guruduth Banavar Gary Lindstrom Department of Computer Science University of Utah Salt LakeCityUT Abstract Wecharacterize ob jectoriented programming as structuring and manipulating a uniform space of rstclass values representing modules a distillation of the notion of classes Op erators over mo dules individually achieve eects such as encapsulation sharing and static binding A variety of idioms of OO programming nd convenient expression within this mo del including several forms of single and multiple inheritance abstract classes class variables inheritance hierarchy combination and reection Weshow that this programming style simplies OO programming via enhanced uniformity and supp orts a exible mo del of ob jectorientation that provides an attractive alternative to metaprogramming Finallyweshow that these notions of OO programming are language indep endent by implementing a Mo dular Scheme prototyp e as a completion of a generic OO framework for mo dularity Pap er Category Research Topic Area Language design and implementation Intro duction Classbased ob jectoriented programming is usually thought of as creating a graph structured inher itance hierarchy of classes instantiating some of these classes and computing with these instances Instances are typically rstclass values in the language ie they can b e created stored accessed and passed into and out of functions Classes on the other hand are usually not rstclass values and inheritance is
  • Opening Presentation

    Opening Presentation

    Mono Meeting. Miguel de Icaza [email protected] October 24, 2006 Mono, Novell and the Community. Mono would not exist without the community: • Individual contributors. • Companies using Mono. • Organizations using Mono. • Companies using parts of Mono. • Google Summer of Code. Introductions. 2 Goals of the Meeting. A chance to meet. • Most of the Novell/Mono team is here. • Many contributors are here. • Various breaks to talk. Talk to others! • Introduce yourself, ask questions. Talk to us! • Frank Rego, Mono's Product Manager is here. • Tell us what you need in Mono. • Tell us about how you use Mono. 3 Project Status Goals Originally: • Improve our development platform on Linux. As the community grew: • Expand to support Microsoft APIs. As Mono got more complete: • Provide a complete cross platform runtime. • Allow Windows developers to port to Linux. 5 Mono Stacks and Goals. MySMQySQLL//PPosstgtrgesrsess EvEovolluutitioonn# # ASP.NET Novell APIs: MMoozzillala Novell iFolder iFolder, LDAP, Identity ADO.NET ApAapchachee MMonoono DesktoGpTK#: GTK# OpNoevenlOl LfDfAiPce GCneomceil# Windows.Forms JavaJa vCa oCommpaatitbilbitiylity Google APIs Microsoft Compatibility Libraries Mono Libraries Mono Runtime (Implementation of ECMA #335) 6 Platforms, CIL, Code Generation. 7 API space Mono 1.0: July 2004 “T-Bone” Mono 1.2: November 2006 “Rump steak” Mono 1.2 bits. Reliability and C# 2.0, .NET 2.0 scalability: • Complete. • With VM support. • ZenWorks and iFolder • Some 2.0 API support. pushed Mono on the server. • IronPython works. • xsp 1.0: 8 request/second. • xsp 1.2: 250 Debugger: request/second. • x86 and x86-64 debugger. GUI • CLI-only, limited in scenarios (no xsp).
  • OOP with Java 16

    OOP with Java 16

    OOP with Java 16. Inheritance and Overriding Thomas Weise · 汤卫思 [email protected] · http://iao.hfuu.edu.cn Hefei University, South Campus 2 合肥学院 南艳湖校区/南2区 Faculty of Computer Science and Technology 计算机科学与技术系 Institute of Applied Optimization 应用优化研究所 230601 Shushan District, Hefei, Anhui, China 中国 安徽省 合肥市 蜀山区 230601 Econ. & Tech. Devel. Zone, Jinxiu Dadao 99 经济技术开发区 锦绣大道99号 Outline 1 Introduction 2 Extending Classes and Class Hierarchy 3 Multi-Level Inheritance 4 The Class Object 5 static vs. instance methods 6 Summary website OOPwithJava ThomasWeise 2/23 Introduction • So far, we have basically treated as objects as data structures and used methods to work on them OOPwithJava ThomasWeise 3/23 Introduction • So far, we have basically treated as objects as data structures and used methods to work on them • But Object-Oriented Programming is much more OOPwithJava ThomasWeise 3/23 Introduction • So far, we have basically treated as objects as data structures and used methods to work on them • But Object-Oriented Programming is much more • The true power of OOP arises from class inheritance and extension (often called specialization) OOPwithJava ThomasWeise 3/23 Extending Classes • A class Student can extend another class Person OOPwithJava ThomasWeise 4/23 Extending Classes • A class Student can extend another class Person • Student inherits all the fields and functionality of the original class Person OOPwithJava ThomasWeise 4/23 Extending Classes • A class Student can extend another class Person • Student inherits all the fields and functionality
  • Programming in JAVA Topic: • a Closer Look at Methods And

    Programming in JAVA Topic: • a Closer Look at Methods And

    B. Sc. (H) Computer Science Semester II BHCS03 – Programming in JAVA Topic: A Closer Look at Methods and Classes Inheritance Command Line Arguments The java command-line argument is an argument i.e. passed at the time of running the java program. The arguments passed from the console can be received in the java program and it can be used as an input. So, it provides a convenient way to check the behavior of the program for the different values. You can pass N (1,2,3 and so on) numbers of arguments from the command prompt. Simple example of command-line argument In this example, we are receiving only one argument and printing it. To run this java program, you must pass at least one argument from the command prompt. class CommandLineExample{ public static void main(String args[]){ System.out.println("Your first argument is: "+args[0]); } } compile by > javac CommandLineExample.java run by > java CommandLineExample sonoo Output: Your first argument is: sonoo Varargs: Variable length arguments A method with variable length arguments(Varargs) in Java can have zero or multiple arguments. Variable length arguments are most useful when the number of arguments to be passed to the method is not known beforehand. They also reduce the code as overloaded methods are not required. Example public class Demo { public static void Varargs(String... str) { System.out.println("\nNumber of arguments are: " + str.length); System.out.println("The argument values are: "); for (String s : str) System.out.println(s); } public static void main(String args[]) { Varargs("Apple", "Mango", "Pear"); Varargs(); Varargs("Magic"); } } Output Number of arguments are: 3 The argument values are: Apple Mango Pear Number of arguments are: 0 The argument values are: Number of arguments are: 1 The argument values are: Magic Overloading Varargs Methods Overloading allows different methods to have same name, but different signatures where signature can differ by number of input parameters or type of input parameters or both.
  • Modular Programming with Functions

    Modular Programming with Functions

    CHAPTER 4 MODULAR PROGRAMMING WITH FUNCTIONS Copyright © 2013 Pearson Education, Inc. Modularity •A program may also contain other functions, and it may refer to functions in another file or in a library. These functions , or modules , are sets of statements that perform an operation or compute a value •To maintain simplicity and readability in long and complex programs, we use a short main, and other functions instead of using one long main function. •By separating a solution into a group of modules, each module is easier to understand, thus adhering to the basic guidelines of structured programming Copyright © 2013 Pearson Education, Inc. Modularity •Braking a problem into a set of modules has many advantages: 1. Every module can be written and tested separately from the rest of the program 2. A module is smaller than a complete program, so testing is easier 3. Once a module has been tested, it can be used in new program without having to retest it ( reusability ) 4. Use of modules ( modularity ) usually reduces the overall length of programs 5. Several programmers can work on the same project if it is separated into modules Copyright © 2013 Pearson Education, Inc. Modularity Main Modules Copyright © 2013 Pearson Education, Inc. Function Definition •A function consists of a definition statement followed by declarations and statements. The general form of a function is: return_type function_name(parameter_declarations) { declarations; statements; return expression; } •The parameter declarations represent the information passed to the function •Additional variables used by the function are defined in declarations statement •All functions should include a return statement Copyright © 2013 Pearson Education, Inc.
  • Metadefender Core V4.13.1

    Metadefender Core V4.13.1

    MetaDefender Core v4.13.1 © 2018 OPSWAT, Inc. All rights reserved. OPSWAT®, MetadefenderTM and the OPSWAT logo are trademarks of OPSWAT, Inc. All other trademarks, trade names, service marks, service names, and images mentioned and/or used herein belong to their respective owners. Table of Contents About This Guide 13 Key Features of Metadefender Core 14 1. Quick Start with Metadefender Core 15 1.1. Installation 15 Operating system invariant initial steps 15 Basic setup 16 1.1.1. Configuration wizard 16 1.2. License Activation 21 1.3. Scan Files with Metadefender Core 21 2. Installing or Upgrading Metadefender Core 22 2.1. Recommended System Requirements 22 System Requirements For Server 22 Browser Requirements for the Metadefender Core Management Console 24 2.2. Installing Metadefender 25 Installation 25 Installation notes 25 2.2.1. Installing Metadefender Core using command line 26 2.2.2. Installing Metadefender Core using the Install Wizard 27 2.3. Upgrading MetaDefender Core 27 Upgrading from MetaDefender Core 3.x 27 Upgrading from MetaDefender Core 4.x 28 2.4. Metadefender Core Licensing 28 2.4.1. Activating Metadefender Licenses 28 2.4.2. Checking Your Metadefender Core License 35 2.5. Performance and Load Estimation 36 What to know before reading the results: Some factors that affect performance 36 How test results are calculated 37 Test Reports 37 Performance Report - Multi-Scanning On Linux 37 Performance Report - Multi-Scanning On Windows 41 2.6. Special installation options 46 Use RAMDISK for the tempdirectory 46 3. Configuring Metadefender Core 50 3.1. Management Console 50 3.2.
  • Scope in Fortran 90

    Scope in Fortran 90

    Scope in Fortran 90 The scope of objects (variables, named constants, subprograms) within a program is the portion of the program in which the object is visible (can be use and, if it is a variable, modified). It is important to understand the scope of objects not only so that we know where to define an object we wish to use, but also what portion of a program unit is effected when, for example, a variable is changed, and, what errors might occur when using identifiers declared in other program sections. Objects declared in a program unit (a main program section, module, or external subprogram) are visible throughout that program unit, including any internal subprograms it hosts. Such objects are said to be global. Objects are not visible between program units. This is illustrated in Figure 1. Figure 1: The figure shows three program units. Main program unit Main is a host to the internal function F1. The module program unit Mod is a host to internal function F2. The external subroutine Sub hosts internal function F3. Objects declared inside a program unit are global; they are visible anywhere in the program unit including in any internal subprograms that it hosts. Objects in one program unit are not visible in another program unit, for example variable X and function F3 are not visible to the module program unit Mod. Objects in the module Mod can be imported to the main program section via the USE statement, see later in this section. Data declared in an internal subprogram is only visible to that subprogram; i.e.
  • A Parallel Program Execution Model Supporting Modular Software Construction

    A Parallel Program Execution Model Supporting Modular Software Construction

    A Parallel Program Execution Model Supporting Modular Software Construction Jack B. Dennis Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 U.S.A. [email protected] Abstract as a guide for computer system design—follows from basic requirements for supporting modular software construction. A watershed is near in the architecture of computer sys- The fundamental theme of this paper is: tems. There is overwhelming demand for systems that sup- port a universal format for computer programs and software The architecture of computer systems should components so users may benefit from their use on a wide reflect the requirements of the structure of pro- variety of computing platforms. At present this demand is grams. The programming interface provided being met by commodity microprocessors together with stan- should address software engineering issues, in dard operating system interfaces. However, current systems particular, the ability to practice the modular do not offer a standard API (application program interface) construction of software. for parallel programming, and the popular interfaces for parallel computing violate essential principles of modular The positions taken in this presentation are contrary to or component-based software construction. Moreover, mi- much conventional wisdom, so I have included a ques- croprocessor architecture is reaching the limit of what can tion/answer dialog at appropriate places to highlight points be done usefully within the framework of superscalar and of debate. We start with a discussion of the nature and VLIW processor models. The next step is to put several purpose of a program execution model. Our Parallelism processors (or the equivalent) on a single chip.
  • The Best of Both Worlds?

    The Best of Both Worlds?

    The Best of Both Worlds? Reimplementing an Object-Oriented System with Functional Programming on the .NET Platform and Comparing the Two Paradigms Erik Bugge Thesis submitted for the degree of Master in Informatics: Programming and Networks 60 credits Department of Informatics Faculty of mathematics and natural sciences UNIVERSITY OF OSLO Autumn 2019 The Best of Both Worlds? Reimplementing an Object-Oriented System with Functional Programming on the .NET Platform and Comparing the Two Paradigms Erik Bugge © 2019 Erik Bugge The Best of Both Worlds? http://www.duo.uio.no/ Printed: Reprosentralen, University of Oslo Abstract Programming paradigms are categories that classify languages based on their features. Each paradigm category contains rules about how the program is built. Comparing programming paradigms and languages is important, because it lets developers make more informed decisions when it comes to choosing the right technology for a system. Making meaningful comparisons between paradigms and languages is challenging, because the subjects of comparison are often so dissimilar that the process is not always straightforward, or does not always yield particularly valuable results. Therefore, multiple avenues of comparison must be explored in order to get meaningful information about the pros and cons of these technologies. This thesis looks at the difference between the object-oriented and functional programming paradigms on a higher level, before delving in detail into a development process that consisted of reimplementing parts of an object- oriented system into functional code. Using results from major comparative studies, exploring high-level differences between the two paradigms’ tools for modular programming and general program decompositions, and looking at the development process described in detail in this thesis in light of the aforementioned findings, a comparison on multiple levels was done.
  • Manual Técnico Portal Para El Centro De Capacitación Continua De La Fica

    Manual Técnico Portal Para El Centro De Capacitación Continua De La Fica

    MANUAL TÉCNICO – PORTAL PARA EL CENTRO DE CAPACITACIÓN CONTINUA DE LA FICA MANUAL TÉCNICO PORTAL PARA EL CENTRO DE CAPACITACIÓN CONTINUA DE LA FICA INSTALACIÓN Es necesario instalar Linux Red Hat 8.0 como servidor, agregando los siguientes paquetes mínimos al momento de la instalación: Desktops: - Sistema X Window - Entorno GNOME Aplications: - Editores (Emacs, vi) - Internet gráfica Servers - Herramientas de configuración del servidor - Servidor Web - Servidor de nombres DNS (BIND) - Servidor de bases de datos - Servidor FTP - Servidor de red Development: - Herramientas de desarrollo (automake, gcc, perl, pitón y depuradores) - Desarrollo de software X (aplicaciones para X window) - Desarrollo de software de GNOME (desarrollar GTK+) System - Herramientas de administración (cuentas de usuario, gestión) - Herramientas del sistema PABLO ANDRÉS LANDETA LÓPEZ 1 UTN – FICA -EISI MANUAL TÉCNICO – PORTAL PARA EL CENTRO DE CAPACITACIÓN CONTINUA DE LA FICA - Soporte para impresión Es muy importante instalar la parte de Development, por cuanto vamos a instalar Mono desde su código fuente, y es necesario compilar las librerías utilizando por ejemplo los compiladores de C++ (gcc). Si instalamos Mono utilizando los archivos .rpm al momento de instalar las aplicaciones nos indicará las dependencias necesarias. Una vez que se tiene instalado la versión Red Hat 8.0 de Linux, e instalado la base de datos MySQL, debemos tener los instaladores (código fuente) de Mono que son los siguientes: mono-0.28.tar.gz mcs-0.28.tar.gz xsp-0.5.tar.gz Primeramente abrimos
  • Module 3 Inheritance in Java

    Module 3 Inheritance in Java

    Module 3 Inheritance in Java Inheritance in java is a mechanism in which one object acquires all the properties and behaviors of parent object. The idea behind inheritance in java is that you can create new classes that are built upon existing classes. When you inherit from an existing class, you can reuse methods and fields of parent class, and you can add new methods and fields also. Inheritance represents the IS-A relationship, also known as parent-child relationship. For Method Overriding (so runtime polymorphism can be achieved). For Code Reusability. Syntax of Java Inheritance class Subclass-name extends Superclass-name { KTUNOTES.IN //methods and fields } The extends keyword indicates that you are making a new class that derives from an existing class. In the terminology of Java, a class that is inherited is called a super class. The new class is called a subclass. As displayed in the above figure, Programmer is the subclass and Employee is the superclass. Relationship between two classes is Programmer IS-A Employee.It means that Programmer is a type of Employee. class Employee{ float salary=40000; } class Programmer extends Employee{ int bonus=10000; public static void main(String args[]){ Programmer p=new Programmer(); System.out.println("Programmer salary is:"+p.salary); System.out.println("Bonus of Programmer is:"+p.bonus); } } Programmer salary is:40000.0 Bonus of programmer is:10000 In the above example, Programmer object can access the field of own class as well as of Employee class i.e. code reusability. Downloaded from Ktunotes.in Types of inheritance in java On the basis of class, there can be three types of inheritance in java: single, multilevel hierarchical.
  • Software Quality / Modularity

    Software Quality / Modularity

    Software quality EXTERNAL AND INTERNAL FACTORS External quality factors are properties such as speed or ease of use, whose presence or absence in a software product may be detected by its users. Other qualities applicable to a software product, such as being modular, or readable, are internal factors, perceptible only to computer professionals who have access to the actual software text. In the end, only external factors matter, but the key to achieving these external factors is in the internal ones: for the users to enjoy the visible qualities, the designers and implementers must have applied internal techniques that will ensure the hidden qualities. EXTERNAL FACTORS Correctness: The ability of software products to perform their tasks, as defined by their specification. Correctness is the prime quality. If a system does not do what it is supposed to do, everything else about it — whether it is fast, has a nice user interface¼ — matters little. But this is easier said than done. Even the first step to correctness is already difficult: we must be able to specify the system requirements in a precise form, by itself quite a challenging task. Robustness: The ability of software systems to react appropriately to abnormal conditions. Robustness complements correctness. Correctness addresses the behavior of a system in cases covered by its specification; robustness characterizes what happens outside of that specification. There will always be cases that the specification does not explicitly address. The role of the robustness requirement is to make sure that if such cases do arise, the system does not cause catastrophic events; it should produce appropriate error messages, terminate its execution cleanly, or enter a so-called “graceful degradation” mode.