UNIVERSITI PUTRA MALAYSIA EXTRACTING OBJECT ORIENTED SOFTWARE ARCHITECTURE FROM C++ SOURCE CODE ALI HUSSEIN A. MRESA FSKTM

Size: px

Start display at page:

Download "UNIVERSITI PUTRA MALAYSIA EXTRACTING OBJECT ORIENTED SOFTWARE ARCHITECTURE FROM C++ SOURCE CODE ALI HUSSEIN A. MRESA FSKTM"

Anis Brooke Peters
6 years ago
Views:

1 UNIVERSITI PUTRA MALAYSIA EXTRACTING OBJECT ORIENTED SOFTWARE ARCHITECTURE FROM C++ SOURCE CODE ALI HUSSEIN A. MRESA FSKTM

2 EXTRACTING OBJECT ORIENTED SOFTWARE ARCHITECTURE FROM C++ SOURCE CODE By ALI HUSSEIN A. MRESA Thesis Submitted in Fulfilment of the Requirements for the Degree of Master of Science in the Faculty of Computer Science and Information Technology U niversiti Putra Malaysia October 2000

3 To the Soul of My Sisters AI-forjania and Soad To My Parents II

4 Abstract of thesis presented to Senate of University Putra Malaysia in fulfilment of the requirements for the degree of Master Science. EXTRACTING OBJECT-ORIENTED SOFfW ARE ARCHITECTURE FROM C++ SOURCE CODE By ALI HUSSEIN A. MRESA October 2000 Chairman: Abdul Azim Abdul Ghani, Ph.D. Faculty: Computer Science and Information Technology Software architecture strongly influences the ability to satisfy quality attributes such as modifiability, performance, and security. It is important to be able to analyse and extract information about that architecture. However, architectural documentation frequently does not exist, and when it does, it is often out of sync with the implemented system. In addition, it is not all that software development begins with a clean slate; systems are almost always constrained by the existing legacy code. As a consequence, there is a need to extract information from existing system implementations and reason architecturally about this information. This research presents a reverse engineering tool VOO++ that will read an Object- Oriented C++ source code using UML notation in order to visualise its Class structure and the various relationships that may exist including, inheritance, aggregation, and dependency relationships based on the modified Cohen-Sutherland clipping algorithm. m

5 The idea of clipping is reversed, instead of clipping inside the rectangle, the clipping is done out side the rectangle in terms of four directions (left, right, top, and bottom) and two points represent the centre point fo r each rectangle. An Object-Oriented approach is used to design and implement the tool. Reverse engineering, design pattern, and graphics are the underlying techniques supplied. VOO++ aids an analyst in extracting, manipulating and interpreting the Object-Oriented static model information. By assisting in the reconstruction of static architectures from extracted information, VOO++ helps an analyst to redocument and understand architectures and discover the relationship between "as-implemented" and "asdesigned" architectures. IV

6 Abstrak tesis yang dikemukakan kepada Senat Universiti Putra Malaysia bagi memenuhi keperluan untuk ijazah Master Sains. PENGHASll..AN SENI DINA PERISIAN DERASASKAN ODJEK DARI KOD SUMBER C++ Oleh ALI HUSSEIN A. MRESA Oktober 2000 Pengerusi: Dr. Abdul Azim Abd Ghani, Ph.D. Fakulti: Sains dan Pengajian Alam Sekitar Seni bina perisian sangat mempengaruhi keupayaan untuk memenuhi atribut kualiti seperti kebolehubahan, prestasi dan sekuriti. Adalah penting untuk mampu menganalisa dan menaakul mengenai seni bina tersebut. Walau bagaimanapun dokumentasi seni bina kadang kala wujud, dan bila ianya wujud, ianya tidak selaras dengan sistem yang diimplemen. Tambahan pula tidak semua pembangunan peri sian bermula dengan keperluan baru sepenuhnya; sistem dikekang oleh kewujudan kod legasi. Akibatnya kita perlu mampu menghasilkan maklumat dari implementasi sistem yang sedia ada dan menaakul secara seni bina mengenai maklumat ini. Penyelidikan ini mempersembahkan satu alatan kejuruteraan songsang VOO++ yang dapat membaca kod sumber berorientasi objek C++ dan menghasilkan notasi v

7 UML untuk mengvisualisasi struktur kelas dan pelbagai hubungan yang mungkin wujud termasuk pewarisan, agregasi dan hubungan kebergantungan berdasarkan kepada algoritma perubahan kepitan Cohen-Sutherland. Idea kepitan disongsangkan, sebagai gantian kepada kepitan dalam segi empat, kepitan dilakukan di luar segi empat dalam rangkaian empat arah (kiri, kanan, atas, bawah) dan dua titik mewakili titik tengah untuk setiap empat segi. Pendekatan berorientasikan objek digunakan untuk mereka bentuk dan mengimplemen alatan tersebut. Teknik kejuruteraan songsang, corak reka bentuk dan grafik digunakan sebagai asas. VOO++ membantu penganalisa dalam menghasil, memanipulasi dan menginterpretasi maklumat statik model berorientasikan objek. Dengan membantu dalam membina semula seni bina statik dari maklumat yang terhasil, VOO++ menolong penganalisa untuk mendokumen semula dan memahami seni bina dan mengetahui hubungan diantara seni bina "yang diimplemen" dan "yang direka bentuk". VI

8 ACKNOWLEGEMENTS In the name of Allah, Most Gracious, Most Merciful I would like to take this opportunity to convey my sincere thanks and deepest gratitude to my chairman supervisor Dr. Abdul Azim Abdul Ghani for his advises, comments, suggestions, help, and invaluable guidance, and fruitful discussions throughout my research. I am also indebted to Dr. Ramlan Mahmod and Dr. Md. Nasir sulaiman, members of the supervising committee, for their technical support, suggestions and insights are priceless. I am greatly indebted to the Libyan Ministry of Education for financial support during my study. The contribution of the people at the Libyan Bureau is highly appreciated. lowe the biggest debt to Engineering Academy and my family for their assistance and support. They are the biggest contributors to my success. VII

9 Finally, special mention must be made of all my friends at faculty of computer science and information technology without their knowledge this work would not have been done. These people deserve to be recognised and so I want to do, but I am afraid if I do, I will definitely miss some names. VIn

10 I certify that an Examination Committee met on 5th October 2000 to conduct the final examination of Ali Hussein A. Mresa on his Master thesis entitled "Extracting Object Oriented Software Architecture form C++ Source Code" in accordance with Universiti Pertanian Malaysia ( Higher Degree) Act 1980 and Universiti Pertanian Malaysia (Higher Degree) Regulations The committee recommends that the candidate be awarded the relevant degree. Members of the Examination Committee are as fo llows: Md. Yazid Mohd Saman, Ph.D. Faculty of Computer Science and Information Technology Universiti Putra Malaysia (Chairman) Abdul Azim Abd. Ghani, Ph.D. Faculty of Computer Science and Information Technology Universiti Putra Malaysia (Member) Ramlan Mahmod, Ph.D. Faculty of Computer Science and Information Technology Universiti Putra Malaysia (Member) Md. Nasir Sulaiman, Ph.D. Faculty of Computer Science and Information Technology Universiti Putra Malaysia (Member). GH1tZ"ALI MOHAYIDIN, Ph.D. Pro sorldeputy Dean of Graduate School Universiti Putra Malaysia Date: 1 2 OCT 2000 IX

11 This thesis was submitted to the Senate of Universiti Putra Malaysia and was accepted as fulfilment of the requirements for the degree of Master Science. A.- KAMIS lwgph.d. Associated ProfessorlDean of Graduate School Universiti Putra Malaysia Date: 1 1 JAN zao' x

12 DECLARA TION I hereby declare that the thesis is based on my original work except for quotations and citations, which have been duly acknowledged. I also declare that it has not been previously or concurrently submitted for any other degree at UPM or other institutions. o Name: Ali Hussein A. Mresa Date: IQ-lt>_ 2e>DO XI

13 TABLE OF CONTENTS DEDICATION... '"..,..,..., ABSTRACT ABSTRAK. AC O ED E NTS...,...,... APPROVAL SHEETS V DECLARATION LIST OF TAB ES LIST OF FI URES Page IT ill vn IX XI XVI xvn CHAPTER 1 INTRODUCTION...,..., Background Software Architecture Importance of Software Architecture Software Architecture Issues Research Objectives Thesis Organisation OBJECT-ORIENTED SOF ARE DESI N: PRINCIPLES, BENEFITS, ARCID'I'ECTURE AND REVERSE EN INEERIN TOO S Introduction Object-Oriented Design Principles of Object-Oriented Software Objects Classes Abstraction Encapsulation Polymorphism Modularity Hierarchy Benefits of Object-Oriented Approach Software Architecture Architectural Structures Object-Oriented Software Architecture XII

14 2.8 Object-Oriented Methods Booch Method OMT Method OOSE/Objectory Method OORA Method Unified Modelling Language Reverse Engineering Redocumentation Design Recovery Reverse Engineering Purposes Reverse Engineering Tools Dali CC-RIDER Imagix 4D & Imagix Extracting and Preserving Low-Level Program Rational Rose Case Tool Characteristics of Reverse Engineering Tools Summary OBJECT-ORIENTED METHODOLOGY Introduction Object-Oriented Development Methodology Object-Oriented Development Inputs Methodology Steps Use Cases Develop Message Flow Diagrams Develop Collaboration Diagrams Identify Classes Identify Class Attributes Identify Responsibility Identify Subsystems Identify Contracts Develop Hierarchy Diagrams Summary VOO++ SOFTWARE DESIGN AND IMPLEMENTATION Introduction Business Phase Prerequisites Activities Deliverables VOO++ Functional Requirement VOO++ Non-Functional Requirement XIII

15 4.3 Analysis Phase Prerequisites Activities Write Use Cases Extract Noun List From Use Cases And Initial Requirements Documentation Identify and Document Application Classes from the Noun List Design Phase Prerequisites Activities Identify Classes and its Responsibilities Search the Reuse Library for Applicable Components Implementation Phase Document the Target Language, Hardware, and Software Platforms Major Data Structures In VOO++ Application Class Table Class Table Relationships Data Base Major Graphics Techniques ofvoo++ Application Mathematics Preliminaries Modified Cohen-Sutherland Clipping Implementation Class Relationships Implementation User Interface Summary RESULTS AND DISCUSSION Introduction Bill-of-Material Case Study Bill-of-Materials Classes Bill-of-Materials Aggregation Relationships Bill-of-Materials Inheritance Relationships Bill-of-Materials Dependency Relationships Bill-of-Materials Class Diagrams Buffer-Module Case Study General Class Specification Operations Class Specification Attributes Class Specification Member List Class Specification Reports XIV

16 LogicaI View Report File Summary Report Class Summary Report Documentation Consequence Summary CONCLUSION AND FUTURE WORK REFERENCES Conclusion Future Work APPENDIX A UMI.., Notation B Complete VOO++ Software Application C Summary of the C++ language (Subset of C++) D Buffer-Module Case Study Source File VITA '" xv

17 LIST OF TABLES Table Page 5. 0 TListBuffer Class Operations Specification TListBuffer Class Attributes Specification TListBuffer Class Members List VOO++ File Summary Report of Bill-of-Materials VOO++ Class Summary Report of Bill-of-Materials XVI

18 LIST OF FIGURES Figure Page 2. 0 Communication Between Objects......, Dali Workbench A Derived Relationships..., ,....., CC-RIDER Architecture...,....,......, File Used Tree CC-RIDDER Sample Output , Class Hierarchy CC-RIDDER Sample Output....,..., File Structure (Imagix) Class Structure (Imagix) Module Diagrams Using UML Notation Class Diagrams Using UML Notation , Object-Oriented Development Methodology Inheritance Use Case Scan Use Case..., ,...,..., Part of Visualisation Subsystem ofvoo++ Application VOO++ Subsystems Analysis Phase Prerequisites and Deliverables Basic Architecture for Reverse Engineering, Reengineering Tools...., DocumentlView Interface VOO++ Primitive Classes....., VOO++ Collaboration Diagrams.,...,..., Design Phase Prerequisites and Deliverables Class Table Implementation , Class Table Dynamic Structure ,....., Class Table Relationships Implementation Class Table Relationships Structure DataBase Structure ,.....,...,... '" DataBase Implementation M and N relationship... '" , Start and End Points Relationship The Slope Relation Two Equality Cases..., , Relationships Structure and Notation....., ,....., Shapes Generation...,... '" VOO++ Main Window..., , VOO++PopUp and Bar Menus XVII 43

19 a 5.8 b 5.8 c 5.8 d Al A2 A3 A4 A5 A6 A.7 A8 A9 A10 All A12 B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.lO B.11 B.12 VOO++ About Dialog VOO++ Context Menu , VOO++ Report Dialog Bill-of-Material Classes Definitions Bill-of-Material Classes Rectangles Bill-of-Material Aggregation Relationships Bill-of-Material Inheritance Relationships Bill-of-Material Dependency Relationships Bill-of-Material Static Model Buffer-Module Classes Definitions Buffer-Module Inheritance Relationships Buffer-Module General Class Specification , Buffer-Module General Class Specification Buffer-Module General Class Specification......,.' "., Buffer-Module General Class Specification TListBuffer Class Operations Specification TListBuffer Class Attributes Specification TListBuffer Class Members List VOO++ Logical View Partial Report Bill-of-Material as Designed Class Rectangle Object Rectangle Dependency Relationship Association Relationship Unidirectional Association Relationship Aggregation Relationship by Reference Aggregation Relationship by Value One to One MUltiplicity One to Many Multiplicity Inheritance Relationship Multiple Inheritance Relationship Sequence Diagrams Open Document Sequence Diagram Scan Document Sequence Diagram " Inheritance Sequence Diagram Dependency Sequence Diagram ,. Aggregation Sequence Diagram " Application Classes Sequence Diagram Class Diagrams Sequence Diagram Class Functionality Sequence Diagram (F irst Scenario) Class Functionality Sequence Diagram (Second Scenario) Class Attributes Sequence Diagram (First Scenario) Class Attributes Sequence Diagram (Scenario) ,. Class Specification Sequence Diagram (F irst Scenario) XVIII

20 B. l3 B.14 B. l5 B.16 B. l7 B.18 B. l9 B.20 B.2 1 B.22 B. 23 B.24 B. 25 Class Specification Sequence Diagram (Second Scenario)... Class Functions and Attributes Sequence Diagram... Mouse Facilities Sequence Diagram... General Report Sequence Diagram... Logical View Report Sequence Diagram... Statistics Model Report Sequence Diagram., File Summary Report Sequence Diagram... Class Summary Report Sequence Diagram... VOO++ Collaboration Diagram-(Module Architectures)... VOO++ Collaboration Diagram-Extraction Subsystem... VOO++ Collaboration Diagram- Data Base Subsystem... VOO++ Collaboration Diagram- Visualisation Subsystem... VOO++ Application Reused Classes.., XIX

21 CHAPTER 1 INTRODUCTION "If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process" (Boehm, 1995). 1.1 Background Architectural design has always played a strong role in determining the success of complex software-based systems, the choice of an appropriate architecture can lead to a product that satisfies its requirements and is easily modified as new requirements present themselves, while an inappropriate architecture can be disastrous (Garlan, 1997; Buxton & McDermid, 1991). Despite its importance to software systems engineers, the practice of architectural design has been largely ad hoc, and informal. As a result, architectural designs are often poorly understood by developers; architectural choices are based more on default than solid engineering principles; architectural designs cannot be analysed for consistency or completeness; architectural constraints assumed in the

22 2 initial design are not enforced as a system evolves; and there are virtually no tools to help the architectural designers with their tasks (Garlan, 1997). 1.2 Software Architecture Software architecture concerns the structures of large software systems. The architectural view of a system is an abstract view that distils away details of implementation, algorithm, and data representation and concentrates on the behaviour and interaction of "black-box" components. Software architecture is developed as the first step toward designing a system that has a collection of desired properties. Also the product of software design activities are the definition of the software architecture specification. 1.3 Importance of Software Architecture Fundamentally, there are three reasons why software architecture is important, as follows (Bass et al., 1998). Communication among stakeholders. Software architecture represents common high-level abstraction of a system that most if not all of the system's stakeholders can use as a basis for creating mutual understanding, forming consensus, and communicating with each other.

23 3 Early design decisions. Software architecture represents the manifestation of the earliest design decisions about a system, and these early bindings carry weight far out of proportion to their individual gravity with respect to the system's remaining development, its deployment, and its maintenance life. It is also the earliest point at which the system to be built can be analysed. Transferable abstraction of a system. Software architecture constitutes a relatively small, intellectually graspable model for how a system is structured and how its components work together this model is transferable across systems; in particular, it can be applied to other systems exhibiting similar requirements and can promote large-scale reuse. 1.4 Software Architecture Issues The formal study of software architecture has been a significant addition to the software-engineering repertoire in the 1990s. It has promised much to designers and developers: help with the high-level design of complex systems. Early analysis of high-level designs; particularly with respect to their satisfaction of quality attributes such as modifiability, security, and performance; higher level reuse such as that of designs and enhanced stakeholders communication (Garlan, 1993). These benefits seem enticing. However, much of the promise of software architecture has as yet gone unfulfilled. Some of the problems simply stem from the fact that architectures are seldom documented properly (Kazman & Carriere, 1997) where:

24 4 Many systems have no documented architecture at all. (All systems have an architecture, but frequently it is not explicitly known or recorded by the developers and therefore evolves in an ad hoc fashion.) Architectures are represented in such a way that the relationship between the architectural representation and the actual system, particularly its source code, is unclear. In systems that do have properly documented architectures, the architectural representations are frequently out of sync with the actual system, because maintenance of the system occurs without a similar effort to maintain the architectural representation. There is little completely new development. Development is typically constrained by compatibility with, or use ot: legacy systems. And it is rare that such systems have an accurately documented architecture. Because of these issues, a serious problem in assessing architectural conformance arising, which makes system understanding and maintaining unbearable. Mismatch between "as designed" and "as implemented" system architectures cause much of the value of having an architecture is lost. In addition, when a system enters the maintenance phase of its life cycle, it may sustain modifications that alter its architecture. Hence, a second problem arises: how to ensure that maintenance operations are not eroding the architecture, breaking down abstractions, bridging layers, compromising information hiding, and so forth?

25 5 All of these are manifestations of two Wlderlying causes. The first is that a system does not have "an architecture". It has many: its runtime relationships, data flows, control flows, code structure, and so on. The second, more serious, cause is that the architecture that is represented in a system's docwnentation may not coincide with any of these views. 1.5 Research Objectives With reference to the software architecture issues the research is aiming to develop a prototype reverse-engineering tool base on an Object-Oriented approach with reverse engineering underlying. The proposed tool called VOO++ (Visualisation of Object Oriented Architecture from C+I- source code) that helps the stakeholders to: Re-docwnent Object-Oriented software architecture using an Object Oriented reverse engineering tool, which implies using standard notations UML (unified modelling language) to facilitate the commwlications between project teams. As a result of docwnentation, the relationship between "as designed" and "as implemented" system architecture is presented, which is provided that the software \Blder analysis should be docwnented during its development process. However, the research undertaken will cover the following:

UNIVERSITI PUTRA MALAYSIA

UNIVERSITI PUTRA MALAYSIA CUSTOM WINDOWS PERFORMANCE COUNTERS MONITORING MECHANISM FOR MEASURING QUALITY OF SERVICE ATTRIBUTES AND STABILITY COEFFICIENT IN SERVICE- ORIENTED ARCHITECTURE BAHAREH SADAT