Results 1 - 10
of
793
Preliminary design of jml: a behavioral interface specification language for java
- SIGSOFT Softw. Eng. Notes
"... Abstract JML is a behavioral interface specification language tailored to Java(TM). Besides pre-and postconditions, it also allows assertions to be intermixed with Java code; these aid verification and debugging. JML is designed to be used by working software engineers; to do this it follows Eiffel ..."
Abstract
-
Cited by 476 (40 self)
- Add to MetaCart
(Show Context)
Abstract JML is a behavioral interface specification language tailored to Java(TM). Besides pre-and postconditions, it also allows assertions to be intermixed with Java code; these aid verification and debugging. JML is designed to be used by working software engineers; to do this it follows Eiffel in using Java expressions in assertions. JML combines this idea from Eiffel with the model-based approach to specifications, typified by VDM and Larch, which results in greater expressiveness. Other expressiveness advantages over Eiffel include quantifiers, specification-only variables, and frame conditions. This paper discusses the goals of JML, the overall approach, and describes the basic features of the language through examples. It is intended for readers who have some familiarity with both Java and behavioral specification using pre-and postconditions.
A language and environment for architecture-based software development and evolution.
- In ICSE ’99: Proceedings of the 21st international conference on Software engineering,
, 1999
"... ..."
(Show Context)
RESTful Web Services vs. “Big” Web Services: Making the Right Architectural Decision
- WWW 2008
, 2008
"... Recent technology trends in the Web Services (WS) domain indicate that a solution eliminating the presumed complexity of the WS- * standards may be in sight: advocates of REpresentational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as ..."
Abstract
-
Cited by 151 (16 self)
- Add to MetaCart
(Show Context)
Recent technology trends in the Web Services (WS) domain indicate that a solution eliminating the presumed complexity of the WS- * standards may be in sight: advocates of REpresentational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve enterprise application integration problems and to simplify the plumbing required to build service-oriented architectures. In this paper we objectify the WS- * vs. REST debate by giving a quantitative technical comparison based on architectural principles and decisions. We show that the two approaches differ in the number of architectural decisions that must be made and in the number of available alternatives. This discrepancy between freedom-from-choice and freedom-of-choice explains the complexity difference perceived. However, we also show that there are significant differences
A UML-Based Approach to System Testing
, 2002
"... System testing is concerned with testing an entire system based on its specifications. In the context of object-oriented, UML development, this means that system test requirements are derived from UML analysis artifacts such as use cases, their corresponding sequence and collaboration diagrams, clas ..."
Abstract
-
Cited by 133 (3 self)
- Add to MetaCart
System testing is concerned with testing an entire system based on its specifications. In the context of object-oriented, UML development, this means that system test requirements are derived from UML analysis artifacts such as use cases, their corresponding sequence and collaboration diagrams, class diagrams, and possibly Object Constraint Language (OCL) expressions across all these artifacts. Our goal here is to support the derivation of functional system test requirements, which will be transformed into test cases, test oracles, and test drivers once we have detailed design information. In this paper, we describe a methodology in a practical way and illustrate it with an example. In this context, we address testability and automation issues, as the ultimate goal is to fully support system testing activities with high-capability tools.
Architectural Patterns for Enabling Application Security
, 1998
"... Making an application secure is much harder than just adding a password protected login screen. This paper contains a collection of patterns to be used when dealing with application security. Secure Access Layer provides an interface for applications to use the security of the systems on which they ..."
Abstract
-
Cited by 127 (0 self)
- Add to MetaCart
Making an application secure is much harder than just adding a password protected login screen. This paper contains a collection of patterns to be used when dealing with application security. Secure Access Layer provides an interface for applications to use the security of the systems on which they are built. Single Access Point limits entry into the application through one single point. Check Point gives the developer a way to handle an unknown or changing security policy. Groups of users have different Roles that define what they can and cannot do. The global information about the user is distributed throughout the application with a Session. Finally, users are presented with either a Limited View of legal options or are given a Full View With Errors. These seven patterns work together to provide a security framework for building applications. This paper was submitted, accepted and workshopped at PLoP `97 Copyright 1998. All Rights Reserved. Permission granted to copy for the PLoPD...
Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control
, 2006
"... Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited. ii When separately written programs are composed so that they may cooperate, they ..."
Abstract
-
Cited by 124 (11 self)
- Add to MetaCart
Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited. ii When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference. Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain.
Modular software design with crosscutting interfaces
- IEEE Software
, 2006
"... Aspect-oriented programming languages such as AspectJ offer new mechanisms for decomposing systems into modules and composing modules into systems. This paper introduces crosscut programming interfaces (XPIs) as a practical approach to improving the modular designs of programs written using AspectJ- ..."
Abstract
-
Cited by 77 (4 self)
- Add to MetaCart
(Show Context)
Aspect-oriented programming languages such as AspectJ offer new mechanisms for decomposing systems into modules and composing modules into systems. This paper introduces crosscut programming interfaces (XPIs) as a practical approach to improving the modular designs of programs written using AspectJ-style AOP. It does not limit existing aspect-oriented mechanisms or require new ones.
Model Variables: Cleanly Supporting Abstraction in Design By Contract
, 2003
"... ..."
(Show Context)
jContractor: A Reflective Java Library to Support Design By Contract
, 1998
"... jContractor is a purely library and design-pattern based approach to support Design By Contract specifications such as preconditions, postconditions, class invariants, and recovery and exception handling in Java. jContractor uses an intuitive naming convention, and standard Java syntax to instrument ..."
Abstract
-
Cited by 68 (3 self)
- Add to MetaCart
(Show Context)
jContractor is a purely library and design-pattern based approach to support Design By Contract specifications such as preconditions, postconditions, class invariants, and recovery and exception handling in Java. jContractor uses an intuitive naming convention, and standard Java syntax to instrument Java classes and enforce Design By Contract constructs. The designer of a class specifies a contract by defining protected methods which conform to the jContractor design patterns. jContractor uses Java Reflection to synthesize an instrumented version of a Java class containing jContractor contract specifications. The instrumented version contains code which enforces the Design By Contract specifications. Programmers enable the run-time enforcement of contracts by either incorporating the jContractor class loader or by instantiating objects directly from the instrumented subclass through the jContractor factory. Programmers can use exactly the same syntax for invoking methods and passing ...
