首页 Advanced Software Engineering

Advanced Software Engineering

举报
开通vip

Advanced Software EngineeringAdvanced Software Engineering Advanced Software Engineering: lecture notes - Topic ASE1 by Prof. Dr Jan Pajak Topic ASE1: Introduction to Advanced Software Engineering. (Time of lecturing 3 sessions.) A. Objective. At the end of this session students are ...

Advanced Software Engineering
Advanced Software Engineering Advanced Software Engineering: lecture notes - Topic ASE1 by Prof. Dr Jan Pajak Topic ASE1: Introduction to Advanced Software Engineering. (Time of lecturing 3 sessions.) A. Objective. At the end of this session students are to understand the syllabus, the content of this subject, and the main ideas which are to be elaborated during this course. In other words, this topic mainly is to explain what we are going to learn in this course. It also elaborates on differences between Procedural Programming (PP) and Object-Oriented Programming (OO). B. Delivery and timetable. The subject is delivered for 1 semester in a series of 1 hours lectures twice a week. Lectures are to be presented on Mondays and Wednesdays, 1:30 to 2:45 pm in our PH 1025 lecture theatre. (The Power Point Projector in room PH1025 has a bit “tricky” procedure to follow. It is initiated with setting up the computer (Power Point running and displaying), then it requires the square red switch on the side dashboard to be on, the PC button must be on (red glowing), and the screen lowering switch under it must also be on, finally the “projector” switch must be on and glowing. (If the projector displays the “Sanyo” message, the DVD switch must also be pushed.) C. Syllabus. This course deals with various software engineering areas such as object-oriented SE, system engineering-based SE, component-based SE, architecture-based SE, etc. The analysis covers various issues such as conceptual, methodological, technological, institutional and social issues. Attending students will be able to elevate their capability for trend estimation and total life-cycle engineering in SE field. D. Literature. During compilation of this lecture notes the following textbooks were used as a knowledge base: [1] Allen Macro and John Buxton, “The Craft of Software Engineering”, Addison-Wesley Publishing Company, 1987, ISBN 0-201-18488-5, pb. [2] Ian Sommerville, “Software Engineering”, Third edition, Addison-Wesley Publishing Company, 1989, ISBN 0-201-17568-1, pb. [2b] Ian Sommerville, “Software Engineering”, Eight Edition, Addison-Wesley, Publishing Company, 2007, ISBN 13:978-0-321-31379-9. [3] Roger S. Pressman, “Software Engineering”, Third Edition, McGraw-Hill, Inc. 1992, ISBN 0-07-050814-3, pb. [3b] Roger S. Pressman, “Software Engineering”, Sixth Edition, McGraw-Hill, Inc. 2005, ISBN 0-07-285318-2, hc. E. Electronic copy of lecture notes and other supporting materials. All materials used in this lecture are also available in an electronic Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 1 of 9 version. They can be downloaded from your university web page, as well as from the following public access web pages: pajak.6te.net/ase_1_2007.htm or pajak.6te.net and then click ASE in the Menu 1, or pajak.fateback.com/ase_1_2007.htm or pajak.fateback.com and then click ASE in the Menu 1. Should there be any urgent matter to discuss, I can be contacted through the email address pajakjan@gmail.com , or by ringing me at the extension number 1742. F. Disadvantages and advantages of taking this course in English. This particular course is offered in addition to several others that you can take. Others (apart of this one) are usually lectured in your native tongue. So probably you have a choice to make, namely whether to enrol for a course in your native language, or to enrol to this course in English. To assist you in making this choice, I outlined below disadvantages and advantages of taking this course in the English language: A. Disadvantages: A1.Double difficulty (i.e.: you need to overcome problems with learning Software Engineering, as well as problems how to speak in English with the use of Software Engineering terminology, how to use English textbooks (e.g. [1]), etc.). A2.Communication problems (i.e. I do NOT speak your native language, in turn your knowledge of English is probably rather limited – se we have communication problem at hands). B. Advantages: B1.You are to polish your English skills (i.e. you are to learn English better). In turn “English is a key to the big world”. B2.You learn English terminology relating to Software Engineering, Computer Sciences, etc. B3.You learn to use English textbooks for Computer Sciences, and English professional Journals, English web pages, etc. (and there is a huge selection of these). B4.You master a key for accessing the most up-to-date knowledge. Whole world now communicates in English. So in order to have an access to the most recent developments, you need to master English terminology from your discipline. B5.You learn to interact with professionals in your discipline from throughout the world. G. Content. #1. Initial definitions. Present textbooks avoid providing the definition of software engineering. Therefore such a definition is difficult to find. The book [1], page 3, provided the so-called “Fritz Bauer?s definition of software engineering” which was first formulated for the software engineering conference in 1969, and then was published in 1972. According to it, software engineering is defined as “the establishment and use of sound engineering principles in order to obtain, economically, software that is reliable and works on real machines”. Another (indirect) definition of software engineering is provided in the book [2] page 3. It states that “software engineering is concerned with software systems which are Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 2 of 9 build by teams rather than individual programmers, uses engineering principles in the development of these systems, and is make up of both technical and non-technical aspects”. In other (my own) words, “Software Engineering is a branch of science which tries to develop best methods for completing large software projects and for making good computer programs”. #2. Differences between software engineering and (conventional) hardware engineering. In spite that software engineering uses engineering principles developed during the mass production of machines and hardware, software as such have many different qualities than hardware. These qualities strongly impact methods used by software engineering. Here are the most important of them (from pp. 10-13 of [3], and pp. 5-7 of [3b]): 1. Software doesn?t “wear out” (as does hardware). Thus once done correctly can be used forever. But software deteriorates. Reasons for this deterioration are (a) computer viruses, (b) new defects introduced when changes are made, (c) hardware failures that affects software, (e) system software imperfections that are affecting applications software, and many more. 2. Software does NOT have “spare parts” (although there are software updates, revisions, modifications, etc.) Therefore, software maintenance involves considerable more complexity than hardware maintenance. 3. Software is developed or engineered, means it is NOT manufactured in the classical sense. Means the costs of software are concentrated in engineering, not e.g. in materials. 4. Most of software must be custom-build rather than being assembled from existing components. Therefore a lot of effort is going into the “software reusability” – hence e.g. the OOP (Object-Oriented Programming). #3. Differences between software engineering and “amateur programming”. Software engineering is aimed at the professional production of high quality software achieved through the employment of sound principles whose effectiveness is successfully proven through implementations in various areas of engineering. The term "amateur programming" refers to the production of software which is more based on the intuition and spontaneity of a programmer than on a solid knowledge of principles and techniques. Such software is less likely to be of a high quality. Main differences between these two approaches. A software engineer produces software in a different manner than an amateur programmer. The main differences in the software engineer's approach concern: 1. A good knowledge and strict meeting of basic requirements imposed on professionally made software, for example: - User friendliness (i.e. making program as easy to operate as possible). - Foolproofing (i.e. safeguarding of computer programs against operator mistakes and incorrect data). 2. A good knowledge of principles and techniques used for software development, especially: Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 3 of 9 - A good knowledge of the software life-cycle which is relevant to the piece of software being developed. - A good knowledge of principles and techniques applicable for each stage of the software life-cycle. 3. The strict adherence to these principles and techniques. 4. A good knowledge, and the wide use, of mutual relationships between the various stages of the software life-cycle. For example: - Shifting the focus of attention from those stages of the life-cycle which for amateur programming traditionally consume the majority of resources (e.g. testing, debugging, and maintenance), into the stages whose quality of completion directly impact the consumption of labour in the traditionally laborious stages (e.g. into the design, specification, etc.). 5. The knowledge and the use of mutual relationships between the various rules and techniques of software development and the impact on the final software that these techniques have. For example: - the connection between the clarity of the program's structure and the labour consumption at the testing, debugging and maintenance stages, - the connection between the use of GOTO statements and the clarity of a program's structure. 6. The strict documentation (especially producing hard documentation) of each stage of software development, similarly to engineers from a contemporary factory documenting rigidly each stage of development of their products. 7. An in-depth knowledge of the type of software being developed, in a similar fashion to engineers developing a given device always displaying an excellent knowledge of other similar products. 8. The re-use of modules, algorithms, and objects. The labour consumption during software production can be significantly reduced, and the reliability of the final software can be increased, through the re-use of algorithms, modules and objects that have already been proven in other applications. For example, there are claims that some products developed by professional software companies in Japan consist of about 50% re-used modules (as a percentage of total code). For other countries this ratio is much smaller. #4. Major milestones in software engineering philosophies and principles. The best way to understand principles of software engineering, is to start from having a look at them from the historic prospective, while noticing how the major milestones and philosophies have gradually emerged. Here is such a historic review: Because we are not certain about various issues of programming, initially we formulate our views about these issues in the form of philosophies. Thus, programming has also its own philosophies (sometimes people refer to them as “approaches”). So-far people developed two basic classes of philosophies of programming, namely: so-called “Procedural Programming (PP)” and “Object- Oriented Programming (OOP)”. In the class of “Procedural Programming” we can further distinguish several individual philosophies, such as “Modular Programming”, “Structured Programming”, and several other - less known ones. PP (Procedural Programming) stage of software engineering. This stage was dominant since times of first computers, until around 2000, with a changeover period slowly starting around 1995. Practically even now many simple tasks is done with the use of PP. Procedural Programming is an approach to programming, or a philosophy of programming, in which programs are formulated as series of procedures which tell the computer what and how should be done. Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 4 of 9 - Spaghetti programming stage. It was started by the “Bohm and Jacopini Theorem” (1966), which identified sequence, selection, and repetition as a necessary parts of computer programs. The consequence was initially the GO TO statement, and thus also “spaghetti programs”. - Data Independence idea. Data independence is an approach to programming in which the programs' operation is defined independently from data content. This allows for logical (i.e. defining what) and physical (i.e. defining how) changes in data without altering the applications software that manipulates this data. - Modular Programming concept. (The formation of re-usable modules and libraries of modules – early 1960s.) This is the approach to programming in which the entire problem is divided into a set of routines each, one of which is to be carried out by an independent module of the original program. - Top-down design. The principle of top-down design states that the program's planning activities should be carried out in the direction "from general to specific". In the first stage of planning the "strategy" or the "operational principle" of the program is designed and expressed as a set of control statements contained in the MASTER module. These control statements divide the processing task into a set of steps, each one of which is carried out by a separate "sub-module". In the second stage of planning the purpose of each sub-module is worked out and designed as a set of subordinate routines which, in the next stages, can be nested further into a suitable number of levels. - Structured Programming. Prof Edsgar W. Dijkstra (1976). Structured Programming is a philosophy of writing programs according to a set of rigid rules in order to improve program clarity, simplify debugging, and increase programmer productivity. Sometimes people describe it as “Go-TO free programming” and “one entry one exit programming”. OOP (Object-Oriented Programming) stage of software engineering, and various variations of it. Object-orientation is a new approach to programming, or a new class of philosophies of programming, in which all applications (i.e. processing programs, databases) are organised from smaller components called “objects”, each one of which is containing both the data, and the processing operations, necessary to perform a task. Object oriented approach was invented in order to make programming computers as similar as possible to manufacturing physical goods. Although the basic idea of object orientation is not new, the actual implementation of this idea is rather a fairly recent development in computing, as all the major work on it was done in 1990s. Definition of an “object” by Grady Booch (1986): “An object is a software entity that have state, behaviour, and identity”. Examples of objects from the computing area: an OK button, a scroll box, an icon, a pull-down menu. A new “object-oriented approach” is an alternative (and a competition) to the old “procedural approach”. In the procedural approach programs and databases were created around the process they performed or function they were to fulfil (e.g. previously we had a “sort” program which was created around a specific sorting procedure, now we have a “sort” object which does sorting). To the procedural approach are classified three major philosophies of programming developed so far, namely: top-down design, modular programming, and structured programming (although the OO approach takes some elements from them, e.g. the concept of modules). Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 5 of 9 Object-oriented approach is just another model of reality, applicable for making computer programs, which assumes that the reality can be expressed with the use of a model, which is composed of “objects”. Here are examples of human professions and activities which display these two approaches (i.e. PP and OO): Tailor (PP approach) versus Fashion designer (OO approach), Civil Engineer (PP approach) versus Architect (OO approach). Procedure of cleaning a room, versus a description as how a clean room looks like. Instruction how to write a page, versus a definition as to how a page should look like. #5. Fundamental concepts and terminology of software engineering. Every newly developing discipline, including software engineering, pretends to develop its own terminology. Thus one of the major tasks of learning of a new discipline is to understand its terminology. Now we are undertaking steps to do just this regarding these terms of software engineering, which are covered by our syllabus. Here are subsequent definitions: -object-oriented SE: depicts the engineering of software which is composed of “objects” and the preparation of which follows the object-oriented methodology. -system engineering-based SE: is a variation of software engineering which instead of concentrating solely on software, focuses on a variety of elements, analysing, designing, and organising those elements into a system that can be a product, a service, or a technology for the transformation of information or control. (See [3b] page 122.) -component-based SE (CBSE): is a variation of software engineering which focuses on components of software being developed, such as modules in modular programming or objects in object programming. It is concerned with developing standardised components based on a component model and comprising these into application system ([2b] p. 439). A component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard. ([2b] p. 442). A component model is a definition of standards for component implementation, documentation, and deployment. ([2b] p. 445.) -architecture-based SE. Architecture-Based Software Engineering can be defined as a is a variation of software engineering which concentrates on the architecture design aspect of given software, means on the comprehensive framework that describes the form of structure of this software – its components and how they fit together. (See [3b] page 255.) -issues of SE: subjects from the area of software engineering which are to be discussed or are objects of concern. -conceptual issues: subjects for discussion or concern which relate to main ides of software engineering or software being engineered. -methodological issues: subjects for discussion or concern which relate to procedure or way of doing something in SE. -technological issues: subjects for discussion or concern which relate to ways things work. Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 6 of 9 -institutional issues: subjects for discussion or concern which relate to institutions that produce or use given software. -social issues: subjects for discussion or concern which are concerned with people?s welfare (e.g. RSI – i.e. Repetitive Strain Injury, “cyber dependency”, computer viruses, code of ethics). E.g., in the article “Cyber dependency has far-reaching effects” from p. A11, “The New Zealand Herald”, issue dated on Monday, February 26, 2007, they stated, quote: “… include lethargy, an inability to concentrate, and rudeness. … The effect on one?s IQ is significantly more harmful than taking cannabis.” -software engineering life-cycle: “Lifecycle is the name assigned to sequence of stages through which each software project evolves from the moment when it is conceived to the time when it is withdrawn from further use”. #6. Test questions. Check whether you learned the key points of this topic, by answering the following multi-choice questions: (ASE1-Q1) Which one amongst the following definitions CANNOT be used as a definition of the discipline of software engineering: 1. The establishment and use of sound engineering principles in order to obtain, economically, software that is reliable and works on real machines. 2. The formation of software entities that have state, behaviour, and identity. 3. The building of software systems by teams rather than by individual programmers, through the use of engineering principles in the development of these systems, and make up of both technical and non-technical aspects. 4. The establishment and use of sound engineering principles and good management practice, and the evolution of applicable tools and methods and their use as appropriate, in order to obtain – within known and adequate resource provisions – software that is of high quality in an explicitly defined sense. (Extended Bauer?s, [1] p. 3) (ASE1-Q2) Which factor amongst listed below is the main reason behind the statement that “software does not „wear out? but it deteriorates?: 1. Software is locked inside of memory and not exposed to elements. 2. Software is not creating friction during the operation. 3. Software runs on PCs which use electric impulses for information processing. 4. Software is an expression of algorithms which not made up of any specific materials that could be subjected to wear and tear. (ASE1-Q3) The presence of which combination of distinct features can be characteristic of programmes prepared with “amateur programming” but should not be typical for professionally made programs of software engineers: 1. Displaying user friendliness and foolproofing. 2. Requesting from the user to input current date. 3. Having default data. 4. Code includes modules and/or objects. (ASE1-Q4-PP) The presence of which distinct feature is NOT characteristic for procedural programming (PP): 1. Object. 2. Selection. 3. Top-down design. 4. Module. Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 7 of 9 (ASE1-Q4-OO) The presence of which characteristic is NOT unique just to object-oriented programming (OOP): 1. Polymorphism. 2. Inheritance. 3. Repetition. 4. Object. (ASE1-Q5-Social) Which one amongst following is not a social issue of SE: 1. RSI. 2. Ethics of programmers. 3. Cyber dependency. 4. Generation of microprocessors which our PC uses. Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 8 of 9 #7. Correct answers to test questions from #6. (ASE1-Q1)-2: it is the definition of an “object” from OO, (ASE1-Q2)-4: the lack of materials means the lack of wearing out, (ASE1-Q3)-2: program should always automatically extract the current date from the computer, (ASE1-Q4-PP)-1: selection, together with sequence and repetition can be a part of any programming, (ASE1-Q4-OO)-3: repetition can appear in any kind of programming, (ASE1-Q5-Soc)-4. it is a technological issue rather than social. Issued for ASE by Prof. Dr Jan Pajak on 19 April 2010, at 06:02 ASE - Revision #1 Copyright ? 2007 by Prof. Dr Jan Pajak Introduction, P 9 of 9
本文档为【Advanced Software Engineering】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
is_729658
暂无简介~
格式:doc
大小:66KB
软件:Word
页数:24
分类:
上传时间:2018-04-28
浏览量:20