物件導向軟體之架構(Object-Oriented Software Construction)探討

Describes the results of a study where the impact of object-oriented (OO) design on software quality characteristics is experimentally evaluated. A suite of Metrics for OO Design (MOOD) was adopted to measure the use of OO design mechanisms. Data collected on the development of eight small-sized information management systems based on identical requirements were used to assess the referred impact. Data obtained in this experiment show how OO design mechanisms such as inheritance, polymorphism, information hiding and coupling, can influence quality characteristics like reliability or maintainability. Some predictive models based on OO design metrics are also presented.

/pdf/evaluating-the-impact-of-object-oriented-design-on-software-2mlq7vn22z.pdf

Evaluating the impact of object-oriented design on software quality

Cohesion was first introduced as a software attribute that, when measured, could be used to predict properties of implementations that would be created from a given design. Unfortunately, cohesion, as originally defined, could not be objectively assessed, while more recently developed objective cohesion measures depend on code-level information. We show that association-based and slice-based approaches can be used to measure cohesion using only design-level information. An analytical and empirical analysis shows that the design-level measures correspond closely with code-level cohesion measures. They can be used as predictors of or surrogates for the code-level measures. The design-level cohesion measures are formally defined, have been implemented, and can support software design, maintenance and restructuring.

Measuring design-level cohesion

+ [Tex82]. 0 [Tee94]. 1 [Bab27d, Bab31c, Bab15]. $10.95 [Wim83a]. $1000M [Ano84b]. 108 000 [Bab31c, Bab15]. 108000 [Bab27d]. 129 [Ano93a]. $149.50 [Gra94]. 1791 + 200 = 1991 [Sti91]. $19.95 [Dis91]. $21.50 [Mad86]. $25 [O’H82, Yon75]. $25.00 [Hym78]. $26.50 [Enr80]. $27.95 [L.90]. $28 [Hun96]. $29.95 [Por01]. 3 [EW91, HL93]. $3.95 [LY79]. $32.95 [Ano98]. $35.00 [Ano91d]. $37.50 [Ano91d]. $45.00 [Ano91d]. 653 [CH97]. $7.90 [You82b]. $75.00 [Wol08]. $9.95 [Par89]. 1 [TS85]. 3 [Ano89d]. me [Kno88]. Ada [Bro80]. A 3 [Alb05]. : = [Tex82]. N [RSC93]. q [And99a, And99b].

/pdf/a-bibliography-of-books-and-other-publications-about-the-ada-5fp6raqnu4.pdf

A Bibliography of Books and Other Publications about the Ada Programming Language and Its History

Large software systems are difficult to understand and maintain. Program dependency analysis plays a key role in both understanding and maintenance. This paper discusses hidden dependencies among software components that make both understanding and maintenance hard. A hidden dependency is a relationship between two seemingly independent components, and it is caused by the data flow in a third software component. The paper uses abstract system dependency graphs to define hidden dependencies. It discusses the impact of hidden dependencies on the process of change propagation and also discusses an algorithm that warns about the possible presence of hidden dependencies.

Hidden dependencies in program comprehension and change propagation

A conceptual design for a code analysis knowledge base

Modules are constructs that help implement the principle of information hiding. Some languages provide general purpose modules, while others provide modules that are more specialised. This paper compares the modules that are provided by some languages.

A comparison of module constructs in programming languages

LINDA RISING AND FRANK W. CALLLSSDepartment of Computer Science and Engineering, College of Engineering and AppliedSciences, Arizona State University, Tempe, AZ 85287-5406, U.S.A.SUMMARYThe cohesion and coupling guidelines described by Yourdon, Constantine and Myers have proved usefulaids for the design of modular programs. They have also provided direction for the evaluation of existingmodules, pointing to those candidates for restructuring during perfective maintenance. For languageslike Ada, where support for a higher-level of abstraction is provided in the form of a package, subprogramheuristics are inadequate. This paper examines existing guidelines and taxonomies for the Ada packageand proposes extensions to these schemes. These package-level schemes are applied in a case study ofan existing Ada program.

Problems with determining package cohesion and coupling

Intermodule code analysis is a process by which a programmer can analyze a program consisting of a collection of interconnected modules. A deductive database that records the information needed for intermodule code analysis is presented. The application of a deductive database to this domain utilizes the rule capability for data structuring and facilitates the declarative specification of recursive operations. This deductive database was derived from a conceptual schema, which describes the dependencies that exist in a program. A method for mapping a conceptual schema to a deductive database framework is outlined. An example query is used to show how this database can be used for intermodule code analysis. >

Frank W. Calliss

Papers

A conceptual design for a code analysis knowledge base

A comparison of module constructs in programming languages

Problems with determining package cohesion and coupling

The application of deductive databases to inter-module code analysis

An information-hiding metric