Results 1 - 10
of
770
A Language and Environment for Architecture-Based Software Development and Evolution
- Proc. 21st Int’l Conf. Software Eng. (ICSE ’99
, 1999
"... ..."
(Show Context)
RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision, 17th International World Wide Web Conference (WWW2008
- SOA4All, Enabling the SOA Revolution on a World Wide Scale. Proceedings of the 2nd IEEE International Conference on Semantic Computing ICSCIEEE Computer Society
, 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 145 (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-fromchoice 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 129 (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.
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 125 (12 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.
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 124 (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...
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 80 (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 67 (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 ...
