CSM-396 - The Foundations of Specification I

We develop a Core Specification Theory (CST) as a basis for the mathematical investigation of specification and specification languages

CSM-397 - The Foundations of Specification II

In the Foundations of Specification I, we developed a Specification Theory (CST) to serve as a vehicle to explore the mathematical foundations of specification. A further aspect of this concerns type inference. In this paper we develop and explore a type inference system for CST and use it to illustrate the foundational issues which arise with such systems

Automated Verification of Design Patterns with LePUS3

Specification and [visual] modelling languages are expected to combine strong abstraction mechanisms with rigour, scalability, and parsimony. LePUS3 is a visual, object-oriented design description language axiomatized in a decidable subset of the first-order predicate logic. We demonstrate how LePUS3 is used to formally specify a structural design pattern and prove (‗verify‘) whether any JavaTM 1.4 program satisfies that specification. We also show how LePUS3 specifications (charts) are composed and how they are verified fully automatically in the Two-Tier Programming Toolkit

Discovering the input assumptions in specification refinement coverage

The design of a large chip is typically hierarchical - large modules are recursively expanded into a collection of sub-modules. Each expansion refines the design due to the addition of level specific details. We believe that a similar approach is necessary to scale the capacity of formal property verification technology - as the design gets refined from one level to another, the formal specification must also be refined to reflect the level specific design decisions. At the heart of this approach we propose a checker that identifies the input assumptions under which the refined specification "covers" the original specification. This enables the validation engineer to focus the verification effort on the remaining input scenarios thereby reducing the number of target coverage points for simulation

On malfunctioning software

Artefacts do not always do what they are supposed to, due to a variety of reasons, including manufacturing problems, poor maintenance, and normal wear-and-tear. Since software is an artefact, it should be subject to malfunctioning in the same sense in which other artefacts can malfunction. Yet, whether software is on a par with other artefacts when it comes to malfunctioning crucially depends on the abstraction used in the analysis. We distinguish between “negative” and “positive” notions of malfunction. A negative malfunction, or dysfunction, occurs when an artefact token either does not (sometimes) or cannot (ever) do what it is supposed to. A positive malfunction, or misfunction, occurs when an artefact token may do what is supposed to but, at least occasionally, it also yields some unintended and undesirable effects. We argue that software, understood as type, may misfunction in some limited sense, but cannot dysfunction. Accordingly, one should distinguish software from other technical artefacts, in view of their design that makes dysfunction impossible for the former, while possible for the latter

On malfunctioning software

Artefacts do not always do what they are supposed to, due to a variety of reasons, including manufacturing problems, poor maintenance, and normal wear-and-tear. Since software is an artefact, it should be subject to malfunctioning in the same sense in which other artefacts can malfunction. Yet, whether software is on a par with other artefacts when it comes to malfunctioning crucially depends on the abstraction used in the analysis. We distinguish between “negative” and “positive” notions of malfunction. A negative malfunction, or dysfunction, occurs when an artefact token either does not (sometimes) or cannot (ever) do what it is supposed to. A positive malfunction, or misfunction, occurs when an artefact token may do what is supposed to but, at least occasionally, it also yields some unintended and undesirable effects. We argue that software, understood as type, may misfunction in some limited sense, but cannot dysfunction. Accordingly, one should distinguish software from other technical artefacts, in view of their design that makes dysfunction impossible for the former, while possible for the latter

Sistema de información, apoyado en lenguaje de programación JavaEE, para mejorar el análisis, tratamiento y consolidación de los reportes sobre avance en lecto escritura de alumnos sordos de la fundación Dime Colombia, a través de una plataforma informática.

n.a.El presente trabajo trata sobre el desarrollo de un software a la medida, que da respuesta a la necesidad manifestada por la Fundación Dime Colombia, de contar con una herramienta informática que sistematice, agilice y estandarice el procedimiento para la recepción, consulta y retroalimentación de los reportes pedagógicos sobre los avances académicos en el aprendizaje de lectoescritura, logrados por los alumnos sordos o con discapacidad auditiva, en las tutorías sobre Logogenia de la mencionada Fundación. Con fundamento conceptual sobre Ciclo de vida del Software, Lenguaje UML, Modelo vista controlador, Ingeniería de requisitos, Desarrollo ágil Scrum y Lenguaje Java, el trabajo se ocupó del levantamiento de requerimientos usando la técnica de entrevista con la directora de la Fundación, posteriormente se trabajó un diseño modular que integró componentes de acuerdo con los requisitos especificados y finalmente, se ejecutó la implementación respectiva. El software desarrollado es de tipo aplicativo Web, bajo el esquema de Modelo Vista Controlador, con apoyo en herramientas de tipo “open source”, IDE, UML y Lenguaje de Programación Java. En dicho contexto, este documento informa sobre los elementos utilizados para el mencionado desarrollo, tales como: levantamiento de requerimientos, diagrama o modelo entidad relación, diagramas de casos de uso con sus respectivas descripciones, el diagrama de clases, los diagramas de actividades, el prototipo funcional e información sobre las pruebas realizadas. Palabras clave: Logogenia. Reporte pedagógico. Discapacidad auditiva. Tutoría. Desarrollo de Software.The present work deals with the development of custom software, which responds to the need expressed by the Dime Colombia Foundation, to have a computer tool that systematizes, streamlines and standardizes the procedure for receiving, consulting and providing feedback from users. pedagogical reports on the academic advances in learning to read and write, achieved by deaf or hearing impaired students, in the tutorials on Logogeny of the aforementioned Foundation. With a conceptual foundation on the Software Life Cycle, UML Language, Controller View Model, Requirements Engineering, Scrum Agile Development and Java Language, the work dealt with the gathering of requirements using the interview technique with the director of the Foundation, later a modular design was worked out that integrated components according to the specified requirements and finally, the respective implementation was executed. The software developed is of the Web application type, under the Model View Controller scheme, with support for “open source” type tools, IDE, UML and Java Programming Language. In this context, this document reports on the elements used for the aforementioned development, such as: requirements gathering, entity relationship diagram or model, use case diagrams with their respective descriptions, the class diagram, the activity diagrams, the functional prototype and information on the tests carried out. Keywords: Logogeny. Pedagogical report. Hearing impairment. Tutorships

SIMAPRE

El trabajo de grado se basó en una oportunidad de negocio que se identificó dentro de los talleres automotrices, los cuales carecían de herramientas informáticas para el adecuado re-gistro de los trabajos realizados. Como respuesta a esta necesidad, se propone la creación de una empresa la cual brinde servicios a los talleres automotrices, generando un valor agregado en términos de calidad y dinero.The thesis was defined based on a business opportunity identified in auto repair shops, these shops don t have an automated system that helps them manage their customers and jobs. In order to properly fulfill this need we propose the creation of a company that offers these shops software that fulfills it.Ingeniero (a) de SistemasPregrad