17 research outputs found

    Formalization and model checking of software architectural style

    Get PDF
    Formal analysis is required to check the behavior of the system before implementation of any safety critical system. As the complexity of software increases, the need for reasoning about correct behavior becomes more prominent. Algorithmic analysis of different programs is usually carried out in order to prove their properties of execution. Application of formal method is being considered necessary for modeling, verification, and development of any software or hardware systems. In the formal verification of behavioral model, an attempt has been made to formally describe a real-time system e.g., use of Automated Teller Machine (ATM) in Banks. In this thesis, formal models of ATM system are described using state-based languages such as, Z, B, and Alloy as well as event-based language such as, Monterey Phoenix. Model checking is being carried out by automated tools, viz. Z/EVES, Atelier B, and Alloy Analyzer for Z, B, and Alloy specifications respectively. Furthermore, a comparative analysis of different characteristics shown by varied formal approaches has been presented in this thesis. Software architecture plays an important role in the high level design of a system in terms of components, connectors, and configurations. The main building block of software architecture is an architectural style that provides domain specific design semantics. In the analysis of complex architectural style, an attempt has been made in our work to formalize one complex style e.g., C2 (component and connector) using formal specification language Alloy. For consistency checking of modeling notations, the model checker tool e.g., Alloy Analyzer is used. Alloy Analyzer automatically checks properties such as,compatibility between components and connectors, satisfiability of predicates over the architectural structure, and consistency of an architectural style. For modeling and verification of C2 architectural style, one case study on Cruise Control System has been considered. At the end of this study, performance evaluation of different SAT solvers associated with Alloy Analyzer has been performed in order to assess the quality

    Manifest domains:analysis and description

    Get PDF
    Abstract We show that manifest domains, an understanding of which are a prerequisite for software requirements prescriptions, can be precisely described: narrated and formalised. We show that such manifest domains can be understood as a collection of endurant, that is, basically spatial entities: parts, components and materials, and perdurant, that is, basically temporal entities: actions, events and behaviours. We show that parts can be modeled in terms of external qualities whether: atomic or composite parts, having internal qualities: unique identifications, mereologies, which model relations between parts, and attributes. We show that the manifest domain analysis endeavour can be supported by a calculus of manifest domain analysis prompts: is_entity, is_endurant, is_perdurant, is_part, is_component, is_material, is_atomic, is_composite, has_components, has_materials, has_concrete_type, attribute_names, is_stationary, etcetera; and show how the manifest domain description endeavour can be supported by a calculus of manifest domain description prompts: observe_part_sorts, observe_part_type, observe_components, observe_materials, observe_unique_identifier, observe_mereology, observe_attributes. We show how to model attributes, essentially following Michael Jackson (Software requirements &amp; specifications: a lexicon of practice, principles and prejudices. ACM Press, Addison-Wesley, Reading, 1995 ), but with a twist: The attribute model introduces the attribute analysis prompts is_static_attribute, is_dynamic_attribute, is_inert_attribute, is_reactive_attribute, is_active_attribute, is_autonomous_attribute, is_biddable_attribute and is_programmable_attribute. The twist suggests ways of modeling “access” to the values of these kinds of attributes: the static attributes by simply “copying” them, once, the reactive and programmable attributes by “carrying” them as function parameters whose values are kept always updated, and the remaining, the external_attributes, by inquiring, when needed, as to their value, as if they were always offered on CSP-like channels (Hoare, Communicating sequential processes. C.A.R. Hoare series in computer science. Prentice-Hall International, London, 2004 ). We show how to model essential aspects of perdurants in terms of their signatures based on the concepts of endurants. And we show how one can “compile” descriptions of endurant parts into descriptions of perdurant behaviours. We do not show prompt calculi for perdurants. The above contributions express a method with principles, techniques and tools for constructing domain descriptions. It is important to realise that we do not wish to nor claim that the method can describe all that it is interesting to know about domains. </jats:p

    Gherkin Specification Extension : uma linguagem de especificação de requisitos baseada em Gherkin

    Get PDF
    Orientador: Andrey Ricardo PimentelDissertação (mestrado) - Universidade Federal do Paraná, Setor de Ciências Exatas, Programa de Pós-Graduação em Informática. Defesa : Curitiba, 28/02/2019Inclui referências: p.68-72Área de concentração: Ciência da ComputaçãoResumo: O desenvolvimento de software e composto de varias fases, entre elas esta a fase de elicitacao, negociacao e validacao de requisitos. Nesta fase, geralmente utiliza-se linguagem natural para definir e negociar os requisitos do sistema que sera desenvolvido. Entretanto, as linguagens naturais podem ser ambiguas, dificultando o entendimento do requisito, e portanto a sua negociacao e validacao. Uma das tentativas de solucionar o problema da ambiguidade foi a criacao de linguagens de especificacao de requisitos. Algumas destas linguagens, como Z e Alneelain, utilizam metodos formais na definicao dos requisitos. O problema da utilizacao de metodos formais e que todos que lerao os requisitos devemter conhecimentos em metodos formais, fato que nem sempre e verdade, ja que alguns interessados pelo software, como clientes e analistas de negocios, podem nao ter este conhecimento. Outras linguagens, como i* e KAOS, utilizam elementos graficos para especificar um sistema. Este formato pode complicar o entendimento, pois diagramas grandes tem alta complexidade cognitiva. Para tentar solucionar este problema, e apresentado o Gherkin Specification Extension (GSE), uma extensao da linguagem Gherkin, que utiliza linguagem natural em conjunto de estruturas fixas para reduzir o problema da ambiguidade durante a especificacao de requisitos utilizando linguagem natural. O GSE foi estruturado com base em onze requisitos que definem sete secoes diferentes (Descricao, Grupo, Restricoes e qualidades, Relacionamento, Planejamento, Metricas e Notas). Este requisitos foram estudados de forma a identificar funcionalidades chave para melhorar a comunicacao entre diversos interessados no software, seja ele um desenvolvedor, gerente de projetos, cliente, usuario ou analista de negocios. A extensao foi validada quanto a sua aceitacao com pessoas com poucos conhecimentos em desenvolvimento de software, obtendo resultado positivos referente a qualidade da especificacao gerada e aceitacao da tecnologia. Para mensurar a aceitacao da tecnologia foi utilizado o modelo TAM (Technology Acceptance Model) em sua terceira versao. Palavras-chave: Linguagem, Especificacao, Requisitos.Abstract: Software development consists of several phases, including elicitation, negotiation and validation of requirements. At this stage, natural language is usually used to define and negotiate the system requirements that will be developed. However, natural languages can be ambiguous, making it difficult to understand the requirement, and therefore its negotiation and validation. One of the attempts to solve the ambiguity problem was the creation of requirements specification languages. Some of these languages, such as Z and Alneelain, use formal methods in defining requirements. The problem with using formal methods is that everyone who will read the requirements must have knowledge of formal methods, a fact that is not always true, as some software stakeholders, such as customers and business analysts, may not have this knowledge. Other languages, such as i * and KAOS, use graphics to specify a system. This format may complicate understanding, since very large diagrams generally have high cognitive complexity. In order to solve this problem, the Gherkin Specification Extension (GSE), an extension of the Gherkin language, is presented, which uses natural language in conjunction with fixed structures to reduce the problem of ambiguity during specification of requirements using natural language . The GSE was structured based on eleven requirements that define seven different sections (Description, Group, Constraints and Qualities, Relationship, Planning, Metrics and Notes). These requirements have been studied in order to identify key functionalities to improve communication among diverse stakeholders in the software, be it a developer, project manager, client, user or business analyst. The extension was validated for its acceptance with people with little knowledge in software development, obtaining positive results regarding the quality of the generated specification and acceptance of the technology. To measure the acceptance of the technology, the TAM (Technology Acceptance Model) model was used in its third version. Keywords: Language, Specification, Requirement

    Automated specification-based testing of graphical user interfaces

    Get PDF
    Tese de doutoramento. Engenharia Electrónica e de Computadores. 2006. Faculdade de Engenharia. Universidade do Porto, Departamento de Informática, Escola de Engenharia. Universidade do Minh

    A formal framework for the specification of interactive systems

    Get PDF
    We are primarily concerned with interactive systems whose behaviour is highly reliant on end user activity. A framework for describing and synthesising such systems is developed. This consists of a functional description of the capabilities of a system together with a means of expressing its desired 'usability'. Previous work in this area has concentrated on capturing 'usability properties' in discrete mathematical models. We propose notations for describing systems in a 'requirements' style and a 'specification' style. The requirements style is based on a simple temporal logic and the specification style is based on Lamport's Temporal Logic of Actions (TLA) [74]. System functionality is specified as a collection of 'reactions', the temporal composition of which define the behaviour of the system. By observing and analysing interactions it is possible to determine how 'well' a user performs a given task. We argue that a 'usable' system is one that encourages users to perform their tasks efficiently (i.e. to consistently perform their tasks well) hence a system in which users perform their tasks well in a consistent manner is likely to be a usable system. The use of a given functionality linked with different user interfaces then gives a means by which interfaces (and other aspects) can be compared and suggests how they might be harnessed to bias system use so as to encourage the desired user behaviour. Normalising across different users anq different tasks moves us away from the discrete nature of reactions and hence to comfortably describe the use of a system we employ probabilistic rather than discrete mathematics. We illustrate that framework with worked examples and propose an agenda for further work

    Processo e evolução dos métodos formais na engenharia de requisitos

    Get PDF
    Requirements Engineering is considered the most important phase of the life cycle of software products because it specifies the needs of the customers, and it is also the basis for the execution of the other phases of software engineering. The models currently used to perform the requirements elicitation have been proposed and widely documented, but they are focused only on the techniques to collect information, disregarding the activity of properly documenting this information. Moreover, to structure the requirements specification, natural language continues to be used as a means of communication and understanding with the customer. Due to the ambiguities caused by this language, its interpretation becomes difficult, and this leads to reprocesses in the later stages of the software life cycle. According to the above, it is necessary for software development organizations to consider formalizing the process of requirements elicitation if they wish to make their development process more efficient. A literature review is carried out in this paper to determine the process and evolution of the formal methods from the requirements engineering perspective.La ingeniería de requisitos se considera la fase más importante del ciclo de vida de los productos de software, porque en ella se especifican las necesidades de los clientes y es la base para la ejecución de las demás fases de la ingeniería de software. Los modelos que actualmente se utilizan para realizar la elicitación de requisitos se han propuesto y documentado de forma amplia, pero se centran solo en las técnicas para colectar información y descuidan la actividad de documentarla de manera adecuada. Además, para estructurar la especificación de requisitos sigue en uso el lenguaje natural como forma de comunicación y comprensión con el cliente. Debido a las ambigüedades que este causa, se dificulta la interpretación; esto conlleva reprocesos en las etapas posteriores del ciclo de vida del software. De acuerdo con ello, es necesario que las organizaciones desarrolladoras de software consideren formalizar el proceso de elicitación de requisitos si desean hacer más eficiente su proceso de desarrollo. En este artículo se hace una revisión de literatura para determinar el proceso y evolución de los métodos formales desde la perspectiva de la ingeniería de requisitos. De acuerdo a lo anterior, es necesario que las organizaciones que desarrollan software consideren formalizar el proceso de elicitación de requisitos si desean hacer más eficiente su proceso de desarrollo. En este artículo se hace una revisión de literatura para determinar el proceso y evolución de los métodos formales desde la perspectiva de la Ingeniería de Requisitos.&nbsp;A engenharia de requisitos é considerada a fase mais importante do ciclo de vida dos produtos de software, porque nela se especificam as necessidades dos clientes e é a base para a execução das demais fases da engenharia de software. Os modelos que atualmente são utilizados para realizar a elicitação de requisitos foram propostos e documentados de forma ampla, mas se centram só nas técnicas para coletar informação e descuidam a atividade de documentar de maneira adequada. Além disso, para estruturar a especificação de requisitos segue em uso a linguagem natural como forma de comunicação e entendimento com o cliente. Devido às ambiguidades que este causa, dificulta-se a interpretação; isso implica reprocessos nas etapas posteriores do ciclo de vida do software. De acordo com isso, é necessário que as organizações desenvolvedoras de software considerem formalizar o processo de elicitação de requisitos se desejam tornar mais eficiente seu processo de desenvolvimento. Neste artigo, faz-se uma revisão de literatura para determinar o processo e a evolução dos métodos formais a partir da perspectiva da engenharia de requisitos

    Formal verification of automotive embedded UML designs

    Get PDF
    Software applications are increasingly dominating safety critical domains. Safety critical domains are domains where the failure of any application could impact human lives. Software application safety has been overlooked for quite some time but more focus and attention is currently directed to this area due to the exponential growth of software embedded applications. Software systems have continuously faced challenges in managing complexity associated with functional growth, flexibility of systems so that they can be easily modified, scalability of solutions across several product lines, quality and reliability of systems, and finally the ability to detect defects early in design phases. AUTOSAR was established to develop open standards to address these challenges. ISO-26262, automotive functional safety standard, aims to ensure functional safety of automotive systems by providing requirements and processes to govern software lifecycle to ensure safety. Each functional system needs to be classified in terms of safety goals, risks and Automotive Safety Integrity Level (ASIL: A, B, C and D) with ASIL D denoting the most stringent safety level. As risk of the system increases, ASIL level increases and the standard mandates more stringent methods to ensure safety. ISO-26262 mandates that ASILs C and D classified systems utilize walkthrough, semi-formal verification, inspection, control flow analysis, data flow analysis, static code analysis and semantic code analysis techniques to verify software unit design and implementation. Ensuring software specification compliance via formal methods has remained an academic endeavor for quite some time. Several factors discourage formal methods adoption in the industry. One major factor is the complexity of using formal methods. Software specification compliance in automotive remains in the bulk heavily dependent on traceability matrix, human based reviews, and testing activities conducted on either actual production software level or simulation level. ISO26262 automotive safety standard recommends, although not strongly, using formal notations in automotive systems that exhibit high risk in case of failure yet the industry still heavily relies on semi-formal notations such as UML. The use of semi-formal notations makes specification compliance still heavily dependent on manual processes and testing efforts. In this research, we propose a framework where UML finite state machines are compiled into formal notations, specification requirements are mapped into formal model theorems and SAT/SMT solvers are utilized to validate implementation compliance to specification. The framework will allow semi-formal verification of AUTOSAR UML designs via an automated formal framework backbone. This semi-formal verification framework will allow automotive software to comply with ISO-26262 ASIL C and D unit design and implementation formal verification guideline. Semi-formal UML finite state machines are automatically compiled into formal notations based on Symbolic Analysis Laboratory formal notation. Requirements are captured in the UML design and compiled automatically into theorems. Model Checkers are run against the compiled formal model and theorems to detect counterexamples that violate the requirements in the UML model. Semi-formal verification of the design allows us to uncover issues that were previously detected in testing and production stages. The methodology is applied on several automotive systems to show how the framework automates the verification of UML based designs, the de-facto standard for automotive systems design, based on an implicit formal methodology while hiding the cons that discouraged the industry from using it. Additionally, the framework automates ISO-26262 system design verification guideline which would otherwise be verified via human error prone approaches

    An editor and transformation system for a Z animation case tool.

    Get PDF
    In order to remain competitive, modem systems developers are increasingly under pressure to produce software solutions to complex problems faster and cheaper, whilst at the same time maintaining a high level of quality in the delivered product. One of the key quality measures is the delivery of a system that meets the customer's requirements. Failure to meet the customer's requirements may engender significant re-design, which in turn will cost money, delay product introduction and may seriously damage the developer's credibility. For these reasons, the problem of developing a precise and unambiguous statement of requirements for a proposed system is perhaps one of the most challenging problems within software engineering today. Formal, model-based specification languages such as the Z notation have been widely adopted within the context of requirements engineering, to provide a vehicle for the development of precise and unambiguous specifications. However, the mathematical foundation upon which these notations are based often makes them unapproachable and difficult to assimilate by a non-specialist reader. The problem then faced is that if the customer cannot understand the semantics of the specification, how can the customer agree that the specification is indeed a true reflection of the requirements for the desired system? Several researchers have proposed that rapid prototyping and animation of specifications can be used to increase the customer's understanding of the formal specification. This is achieved by executing specification components on candidate data and observing that the behaviour is as expected. However this requires that the original formal specification be reliably transformed into a representation capable of being executed within a computer system. To achieve this aim requires the support of computer-based tools able to assist the requirements engineer in capturing, manipulating and transforming the formal specification in an efficient and consistent manner. This thesis describes the research and development of the TranZit tool, which is a Z notation editor, checker and transformation system. TranZit supports the efficient capture and maintenance of Z notation specifications using the Windows Graphical User Interface, supported by a suite of powerful language-driven features. In addition TranZit contains a highly integrated and optimised syntax and type checker, combining traditional compiler design techniques with innovative use of object-oriented data structures and methods, to assist the requirements engineer in ensuring the internal consistency of the captured specification. Most importantly, TranZit contains a novel transformation engine, which is capable of transforming a captured Z specification into an executable representation based on extensions to LISP, suitable for direct execution in an animation environment. This process is supported by an eclectic strategy combining automated transformation with user assistance, to overcome many of the well-documented problems associated with transforming non-executable clauses in formal specifications
    corecore