Generic lifecycle support in the ALMA environment

Lamsweerde, Axel van; Delcourt, B.; Delor, E.; Schayes, M C; Champagne, Roger

doi:10.1109/32.6153

Cited by 31 publications

(7 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The ALMA environment described in [35] models software artifacts. Here, the development, analysis, documentation and maintenance of software artifacts are supported during the entire lifecycle.…”

Section: Case Environmentsmentioning

confidence: 99%

Deferring elimination of design alternatives in object‐oriented methods

Akşit

Marcelloni

2001

Concurrency and Computation

View full text Add to dashboard Cite

While developing systems, software engineers generally have to deal with a large number of design alternatives. Current object-oriented methods aim to eliminate design alternatives whenever they are generated. Alternatives, however, should be eliminated only when sufficient information to take such a decision is available. Otherwise, alternatives have to be preserved to allow further refinements along the development process. Too early elimination of alternatives results in loss of information and excessive restriction of the design space. This paper aims to enhance the current object-oriented methods by modeling and controlling the design alternatives through the application of fuzzy-logic-based techniques. By using an example method, it is shown that the proposed approach increases the adaptability and reusability of design models. The method has been implemented and tested in our experimental CASE environment

show abstract

Section: Case Environmentsmentioning

confidence: 99%

Deferring elimination of design alternatives in object‐oriented methods

Akşit

Marcelloni

2001

Concurrency and Computation

View full text Add to dashboard Cite

show abstract

“…One approach to address this would be use to GENII to interface GENOA to the data structures built by a symbolic debugger. Another approach would be to interface GENOA as a querying mechanism to project management databases [Horowitz and Williamson 1985;Penedo 1986;van Lamsweerde et al 1988] this would allow access to project management information in addition to source code information. Indeed, the front-end-retargeting approach might be a useful way to adapt project management databases to "difficult" languages like Cϩϩ and to variant dialects.…”

Section: Interfacing To the Asg Data Structuresmentioning

confidence: 99%

GENOA—a customizable, front-end-retargetable source code analysis framework

Dévanbu

1999

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

Code analysis tools provide support for such software engineering tasks as program understanding, software metrics, testing, and reengineering. In this article we describe GENOA, the framework underlying application generators such as Aria and GENϩϩ which have been used to generate a wide range of practical code analysis tools. This experience illustrates front-end retargetability of GENOA; we describe the features of the GENOA framework that allow it to be used with different front ends. While permitting arbitrary parse tree computations, the GENOA specification language has special, compact iteration operators that are tuned for expressing simple, polynomial-time analysis programs; in fact, there is a useful sublanguage of the GENOA language that can express precisely all (and only) polynomial-time (PTIME) analysis programs on parse trees. Thus, we argue that the GENOA language is a simple and convenient vehicle for implementing a range of analysis tools. We also argue that the "front-end reuse" approach of GENOA offers an important advantage for tools aimed at large software projects: the reuse of complex, expensive build procedures to run generated tools over large source bases. In this article, we describe the GENOA framework and our experiences with it.

show abstract

“…The rules constraining inter-model links allow us to check the structural completeness and consistency of the overall model, e.g., "every conceptual item referenced by a goal specification in the goal model must appear as an attribute or object in the object model, and vice versa"; "an agent responsible for a goal must have the capability of controlling the variables constrained by the goal specification and of monitoring the variables to be evaluated in it", "every operation in the operation model must operationalize at least one leaf goal from the goal model"; "if an agent is responsible for a goal, it must perform all operations operationalizing that goal"; "every state machine capturing the behavior of an agent in the behavior model must show a set of paths prescribed by goals assigned to this agent in the agent model"; etc. To automate such checks, all view types are defined within a common meta-model[21][4]. The structural rules then constrain metamodel components.…”

mentioning

confidence: 99%

“…The structural rules then constrain metamodel components. Many of them take the form:For every instance of metaconcept C1 in the metamodel, there must be a corresponding instance of metaconcept C2, linked to it by an instance of the inter-view link type L. A modeling tool managing the model database can provide a list of precooked queries we can submit for checking such rules automatically[21][31].…”

mentioning

confidence: 99%

Requirements engineering

Lamsweerde

2008

Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering

View full text Add to dashboard Cite

Getting the right software requirements under the right environment assumptions is a critical precondition for developing the right software. This task is intrinsically difficult. We need to produce a complete, adequate, consistent, and well-structured set of measurable requirements and assumptions from incomplete, imprecise, and sparse material originating from multiple, often conflicting sources. The system we need to consider comprises software and environment components including people and devices. A rich system model may significantly help us in this task. Such model must integrate the intentional, structural, functional, and behavioral facets of the system being conceived. Rigorous techniques are needed for model construction, analysis, exploitation, and evolution. Such techniques should support early and incremental reasoning about partial models for a variety of purposes including satisfaction arguments, property checks, animations, the evaluation of alternative options, the analysis of risks, threats, and conflicts, and traceability management. The tension between technical precision and practical applicability calls for a suitable mix of heuristic, deductive, and inductive forms of reasoning on a suitable mix of declarative and operational specifications. Formal techniques should be deployed only when and where needed, and kept hidden wherever possible. The paper provides a retrospective account of our research efforts and practical experience along this route. Problem-oriented abstractions, analyzable models, and constructive techniques were permanent concerns.

show abstract

Generic lifecycle support in the ALMA environment

Cited by 31 publications

References 18 publications

Deferring elimination of design alternatives in object‐oriented methods

Deferring elimination of design alternatives in object‐oriented methods

GENOA—a customizable, front-end-retargetable source code analysis framework

Requirements engineering

Contact Info

Product

Resources

About