Appendix A – Analysis of Software Development MetFoundations of a New ParadigmCourse Outline CS371S Object-oriented Software Development Instructor - J.C. Browne Spring 2004 Course Approach and Goal This course will introduce a model of software system development where an executable program is derived directly from an executable specification called an analysis model. No “code” is written except for a reusable software architecture. The steps in the development cycle are: a) The system is defined as an executable specification which is an object-oriented analysis model. b) The program is validated at the analysis model level. c) A software and execution architecture is defined as a set of class templates in an object-oriented programming system. d) The executable system is realized by compilation of the validated analysis model to the software execution architecture. This method of software development is now being used for high-reliability long-lived systems by leading embedded systems vendors such as Motorola, Xerox and Kodak. Course Materials The course materials include a textbook and some supplementary materials including papers and software system manuals. The text is “Executable UML” A Foundation for Model-Driven Architecture” by S.J. Mellor and M.J. Balcer The lecture notes will be distributed for the first few weeks and will then be available over the web and in hard copy through a distribution service. Work Statement This is essentially a laboratory class. The lectures will cover the xUML and the executable specification based development method in detail and other methods such as alternatives. The main goal of the course will be to carry through a complete development of a small software system using object-oriented development methods. There will be two class examinations but no final examination. The second class examination is scheduled for the last day of class. If there are objections to this date for the second class examination let me know by January 22, 2004. The examinations are open-book and open-notes. Each student must take and pass both examinations. The course grade will be 50% on the project and 50% on theexaminations. Use will be made of commercial software tools which are used in industry. Project Specifications Project Structure - The project will be development of a small software system through the executable specification development methodology. The projects will be executed by small teams of co-workers. I have a set of possible projects. Each team will do a different project. A team can suggest a project of their own definition by preparing a requirements specification and getting it approved. The scale and scope should be similar to the requirements I will circulate. Communication between Students and Instructor The instructor is email oriented. He answers email almost every morning. This is by far the best way to communicate. Formulate your questions in writing and send them to browne@cs. Announcements concerning the class will be sent by email. Read your mail every day. Standards for Conduct Standard University of Texas rules for conduct of classes will be followed. Please make yourself familiar with those rules. Appendix A – Analysis of Software Development Methods Why Software Development by the Conventional Process is Difficult Development of complex software systems has always been a challenging task. (We assume the reader is familiar with the conventional software development process based on manual translation of application designs to implementations in conventional procedural programming languages such a C or C++. The steady increase in functional complexity required for competitive capabilities in software products is compounded by implementation of these systems on distributed and networked systems. But the root causes of the problems of developing software by the convention process of manually programming application operations in procedural programming languages are: (a) The wide conceptual gap between the operations defined in typical application domains and the operations defined in conventional programming languages. The results of this gap are: high complexity for the manual translations from application concepts to programming language concepts and high complexity and low readability of the programs which result. This conceptual gap also impedes validation. (b) In the conventional development process end-user operations of the application are not validated until the programs in procedural programs are have been completed. When complex application operations are realized through complex transformations to complex programs in procedural programming languages, errors of translation areinevitable and execution behaviors become unpredictable. The level of complexity of the program in the procedural language precludes detailed understanding of the entire system while at the same time the system must be validated in terms of application level operations. Additionally there is no provision for validation of the increasing important requirements for performance. (c) Each software development project can make little use of artifacts from past development projects except at the lowest level of data structure library routines. (d) Modifications of functional requirements expressed in application concepts must be done by modification of the procedural program in a different conceptual framework and at a much higher level of complexity. (e) Modifications in execution environment lead to complex ports of the procedural program. It is often difficult to estimate the effort necessary to realize products when the conventional process is used. The products often contain many defects due the difficulty of validation of the procedural program representations. The costs of modifications are high and error prone because they must be done on the procedural program. It is apparent that a qualitative improvement in software development must automate translations from application specifications to procedural languages and that validation must be done in terms of application concepts. Foundations of a New Paradigm The preceding section makes it clear that qualitative improvement in software development process cannot be expected to arise in evolutionary enhancement based on the conventional process. And the analysis given in Section b identifies the steps in the