Maintaining Configurations of Evolving Software Systems

Narayanaswamy, K.; Scacchi, Walt

doi:10.1109/tse.1987.233163

Cited by 57 publications

(20 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…oAS4 can thus support our experimental studies in OA system design and design evolution across families of alternative system configurations (cf. an earlier approach to such problems at [25]). …”

Section: Architectural Design Processmentioning

confidence: 99%

Processes in securing open architecture software systems

Scacchi

Alspaugh

2013

Proceedings of the 2013 International Conference on Software and System Process

View full text Add to dashboard Cite

Our goal is to identify and understand issues that arise in the development and evolution processes for securing open architecture (OA) software systems. OA software systems are those developed with a mix of closed source and open source software components that are configured via an explicit system architectural specification. Such a specification may serve as a reference model or product line model for a family of concurrently sustained OA system versions/variants. We employ a case study focusing on an OA software system whose security must be continually sustained throughout its ongoing development and evolution. We limit our focus to software processes surrounding the architectural design, continuous integration, release deployment, and evolution found in the OA system case study. We also focus on the role automated tools, software development support mechanisms, and development practices play in facilitating or constraining these processes through the case study. Our purpose is to identify issues that impinge on modeling (specification) and integration of these processes, and how automated tools mediate these processes, as emerging research problems areas for the software process research community. Finally, our study is informed by related research found in the prescriptive versus descriptive practice of these processes and tool usage in studies of conventional and open source software development projects.

show abstract

Section: Architectural Design Processmentioning

confidence: 99%

Processes in securing open architecture software systems

Scacchi

Alspaugh

2013

Proceedings of the 2013 International Conference on Software and System Process

View full text Add to dashboard Cite

show abstract

“…Accordingly, modular systems are those whose components can be added, removed, or updated while satisfying the original system functional requirements. Such concepts in turn were integrated into software architectural design language descriptions and configuration management tools [7]. But reliance on software architecture descriptions is not readily found in either conventional game or mod development.…”

Section: Software Extensionmentioning

confidence: 99%

Modding as a basis for developing game systems

Scacchi

2011

Proceedings of the 1st International Workshop on Games and Software Engineering

View full text Add to dashboard Cite

This paper seeks to briefly examine what is known so far about game mods and modding practices. Game modding has become a leading method for developing games by customizing extensions to game software. The research method in this study is observational and qualitative, so as to highlight current practices and issues that can be associated with software engineering foundations. Numerous examples of different game mods and modding practices are identified throughout.

show abstract

“…The contents of these weakly structured documents can be text-processed and understood by people, but because they are not formalized, these documents are often ambiguous and incomplete (Garg andScacchi, 1990, Roth, Aiken, andHobbs 1994). As such, automated mechanisms should be provided to identify and trace relationships across multiple semistructured descriptions of the same system in order to configure, validate, and maintain the consistency of interrelated software descriptions as they evolve (Narayanaswamy and Scacchi, 1987;Choi and Scacchi, 1998).…”

Section: Software Productionmentioning

confidence: 99%

“…Static links denote a simple logical relation between linked software descriptions, whereas operational links imply some standard or user-defined computational processing that is automatically invoked when linked items are visited or modified. In general, as all links indicate some kind of relation, they can be stored and managed by a relational or object-oriented database management system (DBMS) (Narayanaswamy and Scacchi, 1987;Garg andScacchi, 1989,1990;Scacchi, 1991,1998;Wiil 1995: Wiil, Nurnberg,and Leggett 1999. In this way, linked software object descriptions can be indexed, browsed, and relationally queried through the mechanisms of the DBMS, including query processors, report generators, pattern matchers, and fourth generation languages.…”

Section: Software Hypertext Information Structuresmentioning

confidence: 99%

“…However, the presence and formalization of these attributes determines the degree to which the descriptions can be parsed, analyzed, and interpreted by processing mechanisms. Processing tools like language-directed editors, application generators, specification and design analyzers, and compilers to determine their traceability, consistency, completeness, or correctness (Garg and Scacchi, 1990;Narayanaswamy and Scacchi, 1987;Choi and Scacchi, 1998). Subsequently, nodes and forms provide a common, persistently typed substrate for representing and managing software descriptions in ways that facilitate CASE tool integration.…”

Section: Software Hypertext Information Structuresmentioning

confidence: 99%

See 1 more Smart Citation

Hypertext for Software Engineering

Scacchi¹

2002

Encyclopedia of Software Engineering

View full text Add to dashboard Cite

What is the power of hypertext in supporting software engineering? (The term “hypertext” is treated throughout as synonymous with “hypermedia,” which denotes the nonlinear representation of interrelated textual, graphic, filmic, or auditory information.) Power in other contexts usually refers to the ability of some entity or agent to affect the behavior of another or to achieve advantage over another in ways that the other cannot avoid. Following this, one might expect that as a technology , hypertext systems offer relative advantage over alternatives to automated text/document information systems, including conventional word processing systems, file systems, and database management systems. Hypertext systems offer a degree of information processing power that enables new kinds of applications, much like the advent of expert system shells enabled the creation of expert applications for domains such as computer configuration and diagnostic pathology. Similarly, as a medium for writing and reading electronic documents hypertext systems allow the redefinition of the structure and content of documents that alter the constraints and opportunities for conveying information in contrast to the linear print medium. Thus the power of hypertext in whatever form it exists is subtle and incremental; it is potential rather than kinetic. However, such power can accumulate in different application domains in the long run if effectively mobilized and integrated with domain‐specific tasks, processing mechanisms, and workflows. The power of hypertext technology in different application domains can be realized in a number of ways. In particular, technology that supports a unified view of the hypertext documents, production processes, processing mechanisms, and settings of use appears to offer the greatest power at this time. To see this, the concept of a domain‐specific hypertext environment (DSHE) is defined in the following section. Next, the domain of software production is examined in order to identify how hypertext tools and document production/consumption techniques can play a role to facilitate software engineering objectives. The focus then shifts to describe the structure of information to evolve within a DSHE in terms of product, task, and setting information for the domain of software production. Together, these sections then set the final stage for a discussion of the power of DSHE. Subsequently, seven ways the power of DSHE can be realized are identified, followed by an examination of the costs that are borne in order to realize this power.

show abstract

Maintaining Configurations of Evolving Software Systems

Cited by 57 publications

References 18 publications

Processes in securing open architecture software systems

Processes in securing open architecture software systems

Modding as a basis for developing game systems

Hypertext for Software Engineering

Contact Info

Product

Resources

About