A research report submitted to the Faculty of Engineering, University of the Witwatersrand, Johannesburg, in partial fulfilment of the requirements for the degree of Master of Science in Engineering. / Due to the dynamic nature of the software engineering industry there is a constant move towards new strategies for solving design problems. More specifically there is a move towards Object Oriented (OO) methodologies, presumably because of the various advantages offered in terms of maintainability, and reuse of code produced this way. As with various other aspects of the software industry there are however also problems encountered in this transition and lessons to be learned from the experience of companies who have already performed this change. This research report investigates possible guidelines for companies who are currently contemplating a change to the OO software design methodologies, by covering a collection of issues one should know about prior to this change. It also summarises the problems faced in the transition so far, the reasons for these problems and suggests possible solutions. Lastly it also investigates new trends in the OO arena. The emphasis is on South African companies and projects. The results obtained are compared with results obtained overseas to find out what the differences and similarities are. Areas of concern are also identified, where theoreticians' views have been ignored, and both South African and overeeas companies have not implemented any of the suggestions made. / Andrew Chakane 2018

by Liu Shu Cheung, Jimmy. / Thesis (M.Ph.)--Chinese University of Hong Kong, 1988. / Bibliography: leaves 61-64.

Cai Xia. / Thesis (M.Phil.)--Chinese University of Hong Kong, 2002. / Includes bibliographical references (leaves 105-110). / Abstracts in English and Chinese. / Chapter 1 --- Introduction --- p.1 / Chapter 1.1 --- Component-Based Software Development and Quality Assurance Issues --- p.1 / Chapter 1.2 --- Our Main Contributions --- p.5 / Chapter 1.3 --- Outline of This Thesis --- p.6 / Chapter 2 --- Technical Background and Related Work --- p.8 / Chapter 2.1 --- Development Framework for Component-based Software --- p.8 / Chapter 2.1.1 --- Common Object Request Broker Architecture (CORBA) --- p.9 / Chapter 2.1.2 --- Component Object Model (COM) and Distributed COM (DCOM) --- p.12 / Chapter 2.1.3 --- Sun Microsystems's JavaBeans and Enterprise JavaBeans --- p.14 / Chapter 2.1.4 --- Comparison among Different Frameworks --- p.17 / Chapter 2.2 --- Quality Assurance for Component-Based Systems --- p.199 / Chapter 2.2.1 --- Traditional Quality Assurance Issues --- p.199 / Chapter 2.2.2 --- The Life Cycle of Component-based Software Systems --- p.255 / Chapter 2.2.3 --- Differences between components and objects --- p.266 / Chapter 2.2.4 --- Quality Characteristics of Components --- p.27 / Chapter 2.3 --- Quality Prediction Techniques --- p.32 / Chapter 2.3.1 --- ARMOR: A Software Risk Analysis Tool --- p.333 / Chapter 3 --- A Quality Assurance Model for CBSD --- p.35 / Chapter 3.1 --- Component Requirement Analysis --- p.38 / Chapter 3.2 --- Component Development --- p.39 / Chapter 3.3 --- Component Certification --- p.40 / Chapter 3.4 --- Component Customization --- p.42 / Chapter 3.5 --- System Architecture Design --- p.43 / Chapter 3.6 --- System Integration --- p.44 / Chapter 3.7 --- System Testing --- p.45 / Chapter 3.8 --- System Maintenance --- p.46 / Chapter 4 --- A Generic Quality Assessment Environment: ComPARE --- p.48 / Chapter 4.1 --- Objective --- p.50 / Chapter 4.2 --- Metrics Used in ComPARE --- p.53 / Chapter 4.2.1 --- Metamata Metrics --- p.55 / Chapter 4.2.2 --- JProbe Metrics --- p.57 / Chapter 4.2.3 --- Application of Metamata and Jprobe Metrics --- p.58 / Chapter 4.3 --- Models Definition --- p.61 / Chapter 4.3.1 --- Summation Model --- p.61 / Chapter 4.3.2 --- Product Model --- p.62 / Chapter 4.3.3 --- Classification Tree Model --- p.62 / Chapter 4.3.4 --- Case-Based Reasoning Model --- p.64 / Chapter 4.3.5 --- Bayesian Network Model --- p.65 / Chapter 4.4 --- Operations in ComPARE --- p.66 / Chapter 4.5 --- ComPARE Prototype --- p.68 / Chapter 5 --- Experiments and Discussions --- p.70 / Chapter 5.1 --- Data Description --- p.71 / Chapter 5.2 --- Experiment Procedures --- p.73 / Chapter 5.3 --- Modeling Methodology --- p.75 / Chapter 5.3.1 --- Classification Tree Modeling --- p.75 / Chapter 5.3.2 --- Bayesian Belief Network Modeling --- p.80 / Chapter 5.4 --- Experiment Results --- p.83 / Chapter 5.3.1 --- Classification Tree Results Using CART --- p.83 / Chapter 5.3.2 --- BBN Results Using Hugin --- p.86 / Chapter 5.5 --- Comparison and Discussion --- p.90 / Chapter 6 --- Conclusion --- p.92 / Chapter A --- Classification Tree Report of CART --- p.95 / Chapter B --- Publication List --- p.104 / Bibliography --- p.105

I introduce a compositional approach to application software development. In this approach, an extended entity-relationship diagram (EERD), which represents the component types and the relationship types within an application domain, is used as a template of executable programs in that application domain. As we use structural active objects as the components of a program, we can obtain an executable program if those components are instantiated and interconnected as dictated by an EERD. Furthermore, the graphical editor in the proposed software development environment, entity-relationship software development environment (ERSDE), uses EERDs as menus in constructing application software. An EERD used as a menu can enforce legitimate patterns of relationships among components, in addition to providing an intuitive view of available components and possible relationships among them. Two experiments were conducted in order to compare the effectiveness between EERDs and class diagrams of Object Modeling Technique (OMT) and between the ERSDE and the menu-based Structural-Active Object System (SAOS) graphical editors. From these experiments, we obtained the following results. 1. A significant proportion of the subjects who used EERDs to compose certain applications did so correctly, while only a small proportion of the students who used the OMT class diagrams composed these applications correctly. 2. Most of the subjects preferred EERDs to OMT class diagrams as design documents. 3. Although the proportion of the students who composed applications correctly with the ERSDE application editor was larger than the proportion of the students who did so with the menu-based SAOS graphical editors, this difference was statistically not significant. 4. The subjects took significantly longer time to compose applications with the menu-based SAOS editors than with the ERSDE editor. 5. All the subjects preferred the ERSDE application editor to the menu-based SAOS graphical editors as a software development environment. / Graduation date: 1998

Not available / text

No description available.

No description available.

No description available.

No description available.

The purpose of this project was to develop, using Object Oriented Development (OOD), a software tool identified as the Ada Module Description Tool (AMDT). The AMDT provides an automated way to get a module level description of Ada code. A module level description will identify packages, subprograms, objects and type declarations and relationships. This software tool also has the ability to compare Ada source code with a module level description. The comparison shall identify any object, type, subprogram, or package declared in the module level description that does not match the provided source code.The AMDT is made up of two executable programs that run on a VAX/VMS system. The Module Description Generator (MDG) generates a module level description from a set of Ada source code files. The Module Description Checker (MDC) compares a module level description to the Ada source code. Ada is the required High Order Language for the Department Of Defense. The development methodology used was basically Object Oriented Development as described in the book Software Engineerinq With-AAA by Grady Booch and the Software Standards and Procedure Manual for Object Oriented Development (SSPM-M02.04 Draft).Booch's book is a description of Object Oriented Development methodology, while the SSPM is a set of instructions and standard format to implement the methodology. The total design of the AMDT is documented in five segments. The SSPM defines a segment as the code and documentation resulting from a pass through the OOD process. From a Software Quality Engineer's point of view the AMDT would save time in not having to check module descriptions by hand. From the Software Engineer's point of view, when the code is updated a new module description can be generated easily to keep the documentation current with the code. The AMDT tool as written does not find object declarations in the code. Fortunately the effect is minor because the module descriptions needs to be edited anyway. The module description generated by the MDG may have too much information in it. The designer wants only the types, objects, and operations that aid in the understandability of the design and how it is implemented. The only checks the MDC makes are to see if an identifier on the module description is in the code. It does not check to see if there are extra items in the code that should be required in the module description. / Department of Computer Science