| Hrsch W. and Lopes C.V. 1995. Separation of Concerns. Northeastern University, College of Computer Science Technical Report NU-CCS-95-03. February 1995. |
....distribution, etc. can be described into metaobjects at different metalevels and can be composed using interception. The interception of messages allows the interwining of different concerns: the execution of an object s method is suspended to verify constraints, to achieve synchronization, etc. Hrsh 95, Aksit 96] For example, different levels of a reflective architecture are used to implement different parts of the same application in the Operating Systems Apertos [Lea 95] and Mach [Rashid 86] Figure 1. A COO design using roles. COR Class2 Role1 Role2 Class1 In this paper we describe ....
W. Hrsh, C. Lopes. "Separation of Concerns". Technical Report NU-CCS-95-03 of Northeastern University. 1995.
....or be impacted by the change. Change impact analysis provides techniques to address the problem by identifying the likely ripple e ect of software changes and using this information to re engineer the software system design. From the viewpoint of separation of concern in software development [4], we may consider to perform change impact analysis at many levels of software systems during software evolution, for example, at the speci cation, design, architecture, or code level. We may also perform change impact analysis on di erent languages and design paradigms, for example, on ....
W. L. Hursch and C. V. Lopes, \Separation of Concern, \ Technical Report, 1995.
....combine those separate descriptions into a final executable [Kic96] The aspects of a software system can include: data structure, algorithms, distribution, concurrency, security, fault tolerance and synchronisation. Separating these different aspects can produce a number of benefits [Lop95]. These include: a higher level of abstraction allows us to program aspects individually . easier understanding of each aspect because it is not cluttered with other aspects . weak coupling between aspects which provides flexibility and opportunity for re use In separating aspects of a ....
....aspects individually . easier understanding of each aspect because it is not cluttered with other aspects . weak coupling between aspects which provides flexibility and opportunity for re use In separating aspects of a system, synchronisation is typically treated as a single monolithic aspect [Kic96, Lop94, Lop95], yet when viewed as such we find that the benefits of flexibility and re use are not forthcoming. We argue that just as a monolithic, aspect tangling [Kic96] approach to the whole program leads to complex code with limited re use and flexibility, a monolithic approach to synchronisation has ....
Lopes C. V. and Hursch W. L., "Separation of Concerns", College of Computer Science, Northeastern University, Boston, February 1995
....why these occur and how they can in general be avoided. 4.1 Exclusion There are many different ways in which exclusion constraints can be expressed and how the execution state of an object can be maintained and accessed to enforce those constraints. Some languages use declarative statements [Lop95], or annotations [Loh92] to define which methods exclude or are compatible with which others, whilst others use procedural expressions involving synchronisation counters [McH94, Mit95] that report the number of active executions of each message. Conversely most of the active object, Actor based ....
Lopes C. V. and Hursch W. L., "Separation of Concerns", College of Computer Science, Northeastern University, Boston, February 1995
No context found.
Hrsch W. and Lopes C.V. 1995. Separation of Concerns. Northeastern University, College of Computer Science Technical Report NU-CCS-95-03. February 1995.
....observa se que no existe uma tecnologia ou ferramenta nica que oferea todo suporte necessrio, com um nvel de abstrao desejado, para todas as etapas. Em busca de uma resposta a este problema apresentamos a proposio de um modelo baseado em configurao, orientado separao de interesses [Aks 96, Hr 95, Kic 96] e uma metodologia para o desenvolvimento e manuteno de grandes aplicaes distribudas. A idia central desta abordagem oferecer uma alternativa para a concepo de aplicaes distribudas em que a arquitetura de uma aplicao descrita atravs de seus componentes, interaes entre estes componentes, ....
.... de se mapear as descries do nvel de configurao em uma implementao com estruturas e contornos bem definidos [Bis 96] A implementao tradicional de conectores e as interfaces entre mdulos e conectores pode se apresentar difusa e entrelaada com outras partes do cdigo que no dizem respeito interao [Hr 95 e Aks 96] Este problema tem sido contornado com a gerao de esqueletos de cdigo por ferramentas associadas linguagem de configurao ou pela integrao de mecanismos de comunicao dentro das linguagens de programao. O desenvolvimento aplicaes distribudas complexas tem o seu tempo reduzido se houver o ....
[Article contains additional citation context not shown here]
Hrsch, W. L e Lopes, C. V., "Separation of Concerns", 1995.
No context found.
C. Lopes and W. Hursch. Separation of concerns, 1995.
No context found.
Lopes, C.V. and Hursch, W.L., "Separation of Concerns", Tech Report of College of Computer Science, Northeaster University, Boston, MA, Feb. 24, 1995.
No context found.
Lopes, C.V. and Hursch, W.L., "Separation of Concerns", Tech Report of College of Computer Science, Northeaster University, Boston, MA, Feb. 24, 1995.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC