Basic Concepts    of  Software Engineering Chapter I
Computer Science & Software Engineering <ul><li>Computer Science is concerned with  </li></ul><ul><ul><li>Theory  and </li...
Software Process <ul><li>Software process -  set of activities   </li></ul><ul><ul><li>Goal – Development or evolution of ...
Software Process Model <ul><li>Software process model  </li></ul><ul><ul><li>Representation of S/W process in a specific p...
Costs of Software Engineering <ul><li>Roughly 60% of costs are  development costs , 40% are  testing costs .  </li></ul><u...
Software Engineering Methods <ul><li>Structured approaches to software development  includes: </li></ul><ul><li>Model desc...
CASE (Computer-Aided SE) <ul><li>CASE systems </li></ul><ul><ul><li>Intended to provide  automated support for software pr...
Attributes of good software <ul><li>Software should deliver  </li></ul><ul><ul><li>Required functionality  and  performanc...
Challenges  <ul><li>Legacy systems </li></ul><ul><ul><li>Old, valuable systems must be maintained and updated </li></ul></...
Professional and ethical responsibility <ul><li>Software engineering involves wider responsibilities than simply the appli...
Issues of professional responsibility <ul><li>Confidentiality   </li></ul><ul><ul><li>Engineers should normally  respect  ...
Issues of professional responsibility <ul><li>Intellectual property rights   </li></ul><ul><ul><li>Engineers should  be aw...
ACM/IEEE Code of Ethics <ul><li>The  professional societies in the US  have cooperated to produce a code of ethical practi...
Code of ethics - preamble <ul><li>Preamble </li></ul><ul><ul><li>Software engineers shall  commit themselves  to making th...
Code of ethics - principles <ul><li>Public Interest   </li></ul><ul><ul><li>Software engineers shall  act consistently  wi...
Code of ethics - principles <ul><li>Professional Judgement   </li></ul><ul><ul><li>Software engineers shall  maintain inte...
Code of ethics - principles <ul><li>Colleagues   </li></ul><ul><ul><li>Software engineers shall be  fair to and supportive...
Ethical dilemmas <ul><li>Disagreement  in principle with the  policies of senior management </li></ul><ul><li>Your  employ...
Points to remember  <ul><li>Software engineering is an  engineering discipline  which is concerned with all aspects of  so...
Points to remember <ul><li>Methods are organized ways of producing software. They include </li></ul><ul><ul><li>Suggestion...
End
Some Software Characteristics <ul><li>Software is engineered or developed,  not  manufactured in the traditional sense. </...
Some Software Characteristics <ul><li>In theory, software does not wear out at all. </li></ul><ul><li>But, </li></ul><ul><...
Some Software Characteristics <ul><li>Thus, reality is more like this. </li></ul><ul><ul><li>Most serious corporations con...
Some General Approaches <ul><li>Develop and use good engineering practices for building software. </li></ul><ul><li>Make h...
Types of Software Applications <ul><li>Systems Software </li></ul><ul><li>Real-Time Software </li></ul><ul><li>Business So...
Software Myths <ul><li>Myth: It’s in the software.  So, we can easily change it. </li></ul><ul><ul><li>Reality: Requiremen...
Software Myths <ul><li>Myth: Writing code is the major part of creating a software product. </li></ul><ul><ul><li>Reality:...
 
Software Myths <ul><li>Myth: I can’t tell you how well we are doing until I get parts of it running. </li></ul><ul><ul><li...
 
 
The Classical Life Cycle <ul><li>Life-cycle model </li></ul><ul><ul><li>The steps ( phases ) to follow when building softw...
The Classical Life Cycle <ul><li>Requirements phase </li></ul><ul><ul><li>Explore the concept </li></ul></ul><ul><ul><li>E...
The Classical Life Cycle <ul><li>Implementation phase </li></ul><ul><ul><li>Coding </li></ul></ul><ul><ul><li>Unit testing...
1.3.2  The Importance of Postdelivery Maintenance <ul><li>Bad software is discarded </li></ul><ul><li>Good software is mai...
Time (= Cost) of Postdelivery Maintenance Development – 25% Post-Delivery  Maintenance – 75% Total Product Costs Breakout ...
Consequence of  Relative Costs of Phases <ul><li>Suppose Coding method CM new  is 10% faster than currently used method CM...
Requirements, Analysis, and Design Aspects (contd) <ul><li>The earlier we detect and correct a fault, the less it costs us...
Requirements, Analysis, and Design Aspects (contd) <ul><li>The previous figure redrawn on a linear scale </li></ul>Figure ...
Requirements, Analysis, and Design Aspects (contd) <ul><li>To correct a fault early in the life cycle </li></ul><ul><ul><l...
The Author’s Rant <ul><li>Schach claims that, with OO development,  there are no distinct Planning, testing, and documenti...
The Author’s Rant <ul><li>The structured paradigm was successful initially </li></ul><ul><ul><li>It started to fail with l...
Structured versus Object-Oriented Paradigm  <ul><li>Information hiding  </li></ul><ul><li>Need-to-know design </li></ul><u...
Strengths of the Object-Oriented Paradigm <ul><li>With information hiding, postdelivery maintenance is safer </li></ul><ul...
Classical Phases vs Object-Oriented Workflows <ul><li>There is no correspondence between phases and workflows </li></ul><u...
Analysis/Design “Hump” <ul><li>Structured paradigm: </li></ul><ul><ul><li>There is a jolt between analysis (what) and desi...
Removing the “Hump” <ul><li>In the object-oriented paradigm </li></ul><ul><ul><li>Object-oriented analysis </li></ul></ul>...
In More Detail <ul><li>Objects enter here </li></ul><ul><li>Modules (objects) are introduced as early as the object-orient...
1.10  The Object-Oriented Paradigm in Perspective <ul><li>The object-oriented paradigm has to be used correctly </li></ul>...
1.11  Terminology <ul><li>Client, developer, user </li></ul><ul><li>Internal software </li></ul><ul><li>Contract software ...
Terminology (contd) <ul><li>Mistake, fault, failure, error </li></ul><ul><li>Defect  </li></ul><ul><li>Bug     </li></ul>...
Object-Oriented Terminology <ul><li>Data component of an object </li></ul><ul><ul><li>State variable </li></ul></ul><ul><u...
1.12  Ethical Issues <ul><li>There is a code of ethics for Software Engineers. </li></ul><ul><li>What is an example of whe...
Upcoming SlideShare
Loading in...5
×

se

790

Published on

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
790
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
40
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • se

    1. 1. Basic Concepts of Software Engineering Chapter I
    2. 2. Computer Science & Software Engineering <ul><li>Computer Science is concerned with </li></ul><ul><ul><li>Theory and </li></ul></ul><ul><ul><li>Fundamentals. </li></ul></ul><ul><li>Software Engineering is concerned with the practicalities of </li></ul><ul><ul><li>Developing and </li></ul></ul><ul><ul><li>Delivering </li></ul></ul><ul><ul><ul><li>Useful software. </li></ul></ul></ul>
    3. 3. Software Process <ul><li>Software process - set of activities </li></ul><ul><ul><li>Goal – Development or evolution of software </li></ul></ul><ul><li>Generic activities in all software processes are: </li></ul><ul><ul><li>Specification. </li></ul></ul><ul><ul><ul><li>What the system should do and its development constraints. </li></ul></ul></ul><ul><ul><li>Development. </li></ul></ul><ul><ul><ul><li>Production of the software system. </li></ul></ul></ul><ul><ul><li>Validation. </li></ul></ul><ul><ul><ul><li>Checking that the software is what the customer wants. </li></ul></ul></ul><ul><ul><li>Evolution. </li></ul></ul><ul><ul><ul><li>Changing the software in response to changing demands. </li></ul></ul></ul>
    4. 4. Software Process Model <ul><li>Software process model </li></ul><ul><ul><li>Representation of S/W process in a specific perspective </li></ul></ul><ul><li>Examples of process perspectives are </li></ul><ul><ul><li>Workflow perspective - sequence of activities </li></ul></ul><ul><ul><li>Data-flow perspective - information flow </li></ul></ul><ul><ul><li>Role/action perspective - who does what </li></ul></ul><ul><li>Generic process models </li></ul><ul><ul><li>Waterfall </li></ul></ul><ul><ul><li>Evolutionary development </li></ul></ul><ul><ul><li>Formal transformation </li></ul></ul><ul><ul><li>Integration from reusable components </li></ul></ul>
    5. 5. Costs of Software Engineering <ul><li>Roughly 60% of costs are development costs , 40% are testing costs . </li></ul><ul><li>For custom software, evolution costs often exceed development costs. </li></ul><ul><li>Costs vary depending on </li></ul><ul><ul><li>The type of system being developed and </li></ul></ul><ul><ul><li>The requirements of system attributes such as </li></ul></ul><ul><ul><ul><li>Performance and system reliability </li></ul></ul></ul><ul><li>Distribution of costs depends on </li></ul><ul><ul><li>The development model that is used </li></ul></ul>
    6. 6. Software Engineering Methods <ul><li>Structured approaches to software development includes: </li></ul><ul><li>Model descriptions </li></ul><ul><ul><li>Descriptions of graphical models. </li></ul></ul><ul><li>Rules </li></ul><ul><ul><li>Constraints applied to system models. </li></ul></ul><ul><li>Recommendations </li></ul><ul><ul><li>Advice on good design practice. </li></ul></ul><ul><li>Process guidance </li></ul><ul><ul><li>What activities to follow. </li></ul></ul>
    7. 7. CASE (Computer-Aided SE) <ul><li>CASE systems </li></ul><ul><ul><li>Intended to provide automated support for software process activities . </li></ul></ul><ul><li>Upper-CASE </li></ul><ul><ul><li>Tools to support the early process activities </li></ul></ul><ul><ul><ul><li>Requirements and </li></ul></ul></ul><ul><ul><ul><li>Design </li></ul></ul></ul><ul><li>Lower-CASE </li></ul><ul><ul><li>Tools to support later activities such as </li></ul></ul><ul><ul><ul><li>Programming </li></ul></ul></ul><ul><ul><ul><li>Debugging and </li></ul></ul></ul><ul><ul><ul><li>Testing </li></ul></ul></ul>
    8. 8. Attributes of good software <ul><li>Software should deliver </li></ul><ul><ul><li>Required functionality and performance to the user and </li></ul></ul><ul><ul><li>Should be maintainable , dependable and usable </li></ul></ul><ul><li>Maintainability </li></ul><ul><ul><li>Software must evolve to meet changing needs </li></ul></ul><ul><li>Dependability </li></ul><ul><ul><li>Software must be trustworthy </li></ul></ul><ul><li>Efficiency </li></ul><ul><ul><li>Software should not make wasteful use of system resources </li></ul></ul><ul><li>Usability </li></ul><ul><ul><li>Software must be usable by the users for which it was designed </li></ul></ul>
    9. 9. Challenges <ul><li>Legacy systems </li></ul><ul><ul><li>Old, valuable systems must be maintained and updated </li></ul></ul><ul><li>Heterogeneity </li></ul><ul><ul><li>Systems are distributed and include a mix of hardware and software </li></ul></ul><ul><li>Delivery </li></ul><ul><ul><li>There is increasing pressure for faster delivery of software </li></ul></ul>
    10. 10. Professional and ethical responsibility <ul><li>Software engineering involves wider responsibilities than simply the application of technical skills </li></ul><ul><li>Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals </li></ul><ul><li>Ethical behaviour is more than simply upholding the law . </li></ul>
    11. 11. Issues of professional responsibility <ul><li>Confidentiality </li></ul><ul><ul><li>Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. </li></ul></ul><ul><li>Competence </li></ul><ul><ul><li>Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outside their competence. </li></ul></ul>
    12. 12. Issues of professional responsibility <ul><li>Intellectual property rights </li></ul><ul><ul><li>Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright , etc. </li></ul></ul><ul><ul><li>They should be careful to ensure that the intellectual property of employers and clients is protected. </li></ul></ul><ul><li>Computer misuse </li></ul><ul><ul><li>Software engineers should not use their technical skills to misuse other people’s computers. </li></ul></ul><ul><ul><li>Computer misuse ranges from relatively trivial ( game playing on an employer’s machine ) to extremely serious ( dissemination of viruses ). </li></ul></ul>
    13. 13. ACM/IEEE Code of Ethics <ul><li>The professional societies in the US have cooperated to produce a code of ethical practice. </li></ul><ul><li>Members of these organisations sign up to the code of practice when they join. </li></ul><ul><li>The Code contains eight Principles related to the behaviours of professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. </li></ul>ACM - Association for Computing Machinery IEEE – Institute of Electrical and Electronics Engineers
    14. 14. Code of ethics - preamble <ul><li>Preamble </li></ul><ul><ul><li>Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public , software engineers shall adhere to the following Eight Principles: </li></ul></ul>
    15. 15. Code of ethics - principles <ul><li>Public Interest </li></ul><ul><ul><li>Software engineers shall act consistently with the public interest. </li></ul></ul><ul><li>Client and Employer </li></ul><ul><ul><li>Software engineers shall act in the best interests of their client and employer consistent with the public interest. </li></ul></ul><ul><li>Product </li></ul><ul><ul><li>Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. </li></ul></ul>
    16. 16. Code of ethics - principles <ul><li>Professional Judgement </li></ul><ul><ul><li>Software engineers shall maintain integrity and independence in their professional judgment. </li></ul></ul><ul><li>Management </li></ul><ul><ul><li>Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. </li></ul></ul><ul><li>Profession </li></ul><ul><ul><li>Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. </li></ul></ul>
    17. 17. Code of ethics - principles <ul><li>Colleagues </li></ul><ul><ul><li>Software engineers shall be fair to and supportive of their colleagues. </li></ul></ul><ul><li>Self </li></ul><ul><ul><li>Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. </li></ul></ul>
    18. 18. Ethical dilemmas <ul><li>Disagreement in principle with the policies of senior management </li></ul><ul><li>Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system </li></ul><ul><li>Participation in the development of military weapons systems or nuclear systems. </li></ul>
    19. 19. Points to remember <ul><li>Software engineering is an engineering discipline which is concerned with all aspects of software production . </li></ul><ul><li>Software products consist of developed programs and associated documentation . </li></ul><ul><li>Essential product attributes are maintainability, dependability, efficiency and usability . </li></ul><ul><li>The software process consists of activities which are involved in developing software products. Basic activities are software specification, development, validation and evolution . </li></ul>
    20. 20. Points to remember <ul><li>Methods are organized ways of producing software. They include </li></ul><ul><ul><li>Suggestions for the process to be followed </li></ul></ul><ul><ul><li>The notations to be used </li></ul></ul><ul><ul><li>Rules governing the system descriptions. </li></ul></ul><ul><li>CASE tools are software systems </li></ul><ul><ul><li>Designed to support routine activities in the software process. </li></ul></ul><ul><li>Software engineers have responsibilities to the engineering profession and society. </li></ul><ul><li>Professional societies publish codes of conduct which set out the standards of behaviour expected of their members. </li></ul>
    21. 21. End
    22. 22. Some Software Characteristics <ul><li>Software is engineered or developed, not manufactured in the traditional sense. </li></ul><ul><li>Software does not wear out in the same sense as hardware. </li></ul>
    23. 23. Some Software Characteristics <ul><li>In theory, software does not wear out at all. </li></ul><ul><li>But, </li></ul><ul><ul><li>Hardware upgrades. </li></ul></ul><ul><ul><li>Software upgrades. </li></ul></ul>
    24. 24. Some Software Characteristics <ul><li>Thus, reality is more like this. </li></ul><ul><ul><li>Most serious corporations control and constrain changes </li></ul></ul><ul><li>Most software is custom built, and customer never really knows what she/he wants . </li></ul>
    25. 25. Some General Approaches <ul><li>Develop and use good engineering practices for building software. </li></ul><ul><li>Make heavy use of reusable software components. </li></ul><ul><li>Use modern languages that support good software development practices, e.g., Ada95, Java. </li></ul><ul><li>Use 4th generation languages. </li></ul><ul><li>But , almost everything is a two-edged sword. </li></ul><ul><ul><li>Consider long term tool maintenance. </li></ul></ul><ul><ul><ul><li>Right now, this is a major problem for NASA. </li></ul></ul></ul>
    26. 26. Types of Software Applications <ul><li>Systems Software </li></ul><ul><li>Real-Time Software </li></ul><ul><li>Business Software </li></ul><ul><li>Engineering Software </li></ul><ul><li>Embedded Software </li></ul><ul><li>Artificial Intelligence Software </li></ul><ul><li>Personal Computer Software </li></ul>
    27. 27. Software Myths <ul><li>Myth: It’s in the software. So, we can easily change it. </li></ul><ul><ul><li>Reality: Requirements changes are a major cause of software degradation. </li></ul></ul><ul><li>Myth: We can solve schedule problems by adding more programmers. </li></ul><ul><ul><li>Reality: Maybe. It increases coordination efforts and may slow things down . </li></ul></ul><ul><li>Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code. </li></ul><ul><ul><li>Reality: Incomplete up-front definition is the major cause of software project failures. </li></ul></ul>
    28. 28. Software Myths <ul><li>Myth: Writing code is the major part of creating a software product. </li></ul><ul><ul><li>Reality: Coding may be as little as 10% of the effort, and 50 - 70% may occur after delivery. </li></ul></ul>
    29. 30. Software Myths <ul><li>Myth: I can’t tell you how well we are doing until I get parts of it running. </li></ul><ul><ul><li>Reality: Formal reviews of various types both can give good information and are critical to success in large projects. </li></ul></ul><ul><li>Myth: The only deliverable that matters is working code. </li></ul><ul><ul><li>Reality: Documentation, test history, and program configuration are critical parts of the delivery. </li></ul></ul><ul><li>Myth: I am a (super) programmer. Let me program it, and I will get it done. </li></ul><ul><ul><li>Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding. </li></ul></ul>
    30. 33. The Classical Life Cycle <ul><li>Life-cycle model </li></ul><ul><ul><li>The steps ( phases ) to follow when building software </li></ul></ul><ul><ul><li>A theoretical description of what should be done </li></ul></ul><ul><li>Life cycle </li></ul><ul><ul><li>The actual steps performed on a specific product </li></ul></ul><ul><li>Classical model (1970) </li></ul><ul><li>Requirements phase </li></ul><ul><li>Analysis (Specification) Phase </li></ul><ul><li>Design Phase </li></ul><ul><li>Implementation Phase </li></ul><ul><li>Post-delivery Maintenance </li></ul><ul><li>Retirement </li></ul>
    31. 34. The Classical Life Cycle <ul><li>Requirements phase </li></ul><ul><ul><li>Explore the concept </li></ul></ul><ul><ul><li>Elicit the client’s requirements </li></ul></ul><ul><li>Analysis (Specification Phase) </li></ul><ul><ul><li>Analyze the client’s requirements </li></ul></ul><ul><ul><li>Draw up the specification document </li></ul></ul><ul><ul><li>Draw up the software project management plan </li></ul></ul><ul><ul><li>“ What the product is supposed to do” </li></ul></ul><ul><li>Design Phase </li></ul><ul><ul><li>Architectural design, followed by </li></ul></ul><ul><ul><li>Detailed design </li></ul></ul><ul><ul><li>“ How the product does it” </li></ul></ul>
    32. 35. The Classical Life Cycle <ul><li>Implementation phase </li></ul><ul><ul><li>Coding </li></ul></ul><ul><ul><li>Unit testing </li></ul></ul><ul><ul><li>Integration </li></ul></ul><ul><ul><li>Acceptance testing </li></ul></ul><ul><li>Post-delivery maintenance </li></ul><ul><ul><li>Corrective maintenance </li></ul></ul><ul><ul><li>Perfective maintenance </li></ul></ul><ul><ul><li>Adaptive maintenance </li></ul></ul><ul><li>Retirement </li></ul><ul><li>WHICH PHASE IS THE MOST EXPENSIVE </li></ul>
    33. 36. 1.3.2 The Importance of Postdelivery Maintenance <ul><li>Bad software is discarded </li></ul><ul><li>Good software is maintained, for 10, 20 years or more </li></ul><ul><li>Software is a model of reality, which is constantly changing </li></ul>
    34. 37. Time (= Cost) of Postdelivery Maintenance Development – 25% Post-Delivery Maintenance – 75% Total Product Costs Breakout of Development Costs Integration – 29% Implementation/ Coding – 34% Design – 19% Requirements & Analysis – 18%
    35. 38. Consequence of Relative Costs of Phases <ul><li>Suppose Coding method CM new is 10% faster than currently used method CM old . Should it be used? </li></ul><ul><li>Common sense answer  “Of Course” </li></ul><ul><li>BUT: </li></ul><ul><ul><li>What is the cost of training and other overhead? </li></ul></ul><ul><ul><li>Reducing the coding cost by 10% yields at most a 0.85% reduction in total costs </li></ul></ul><ul><ul><li>Consider the expenses and disruption incurred </li></ul></ul><ul><ul><li>Reducing postdelivery maintenance cost by 10% yields a 7.5% reduction in overall costs </li></ul></ul>
    36. 39. Requirements, Analysis, and Design Aspects (contd) <ul><li>The earlier we detect and correct a fault, the less it costs us. </li></ul><ul><li>The cost of detecting and correcting a fault at each phase </li></ul>
    37. 40. Requirements, Analysis, and Design Aspects (contd) <ul><li>The previous figure redrawn on a linear scale </li></ul>Figure 1.6
    38. 41. Requirements, Analysis, and Design Aspects (contd) <ul><li>To correct a fault early in the life cycle </li></ul><ul><ul><li>Usually just a document needs to be changed </li></ul></ul><ul><li>To correct a fault late in the life cycle </li></ul><ul><ul><li>Change the code and the documentation </li></ul></ul><ul><ul><li>Test the change itself </li></ul></ul><ul><ul><li>Perform regression testing </li></ul></ul><ul><ul><li>Reinstall the product on the client’s computer(s) </li></ul></ul><ul><li>Between 60 and 70 percent of all faults in large-scale products are requirements, analysis, and design faults </li></ul><ul><li>Example: Jet Propulsion Laboratory inspections </li></ul><ul><ul><li>1.9 faults per page of specifications </li></ul></ul><ul><ul><li>0.9 per page of design </li></ul></ul><ul><ul><li>0.3 per page of code </li></ul></ul><ul><li>CONCLUSION: It’s vital to improve our techniques to find faults as early as possible. </li></ul>
    39. 42. The Author’s Rant <ul><li>Schach claims that, with OO development, there are no distinct Planning, testing, and documenting phases. </li></ul><ul><li>He says these are continuous operations that don’t have distinct beginnings and endings, but instead are iterative. </li></ul><ul><li>His claim is that this is better than the Classical Model. </li></ul>
    40. 43. The Author’s Rant <ul><li>The structured paradigm was successful initially </li></ul><ul><ul><li>It started to fail with larger products (> 50,000 LOC) </li></ul></ul><ul><li>Postdelivery maintenance problems (today, 70 to 80 percent of total effort) </li></ul><ul><li>Reason: Structured methods are </li></ul><ul><ul><li>Action oriented (e.g., finite state machines, data flow diagrams); or </li></ul></ul><ul><ul><li>Data oriented (e.g., entity-relationship diagrams, Jackson’s method); </li></ul></ul><ul><ul><li>But not both </li></ul></ul>
    41. 44. Structured versus Object-Oriented Paradigm <ul><li>Information hiding </li></ul><ul><li>Need-to-know design </li></ul><ul><li>Impact on maintenance, development </li></ul>Account Balance Message With- drawal Determine Balance Account Balance Deposit Message Message Account Balance Deposit Withdrawal Determine Balance
    42. 45. Strengths of the Object-Oriented Paradigm <ul><li>With information hiding, postdelivery maintenance is safer </li></ul><ul><ul><li>The chances of a regression fault are reduced </li></ul></ul><ul><li>Development is easier </li></ul><ul><ul><li>Objects generally have physical counterparts </li></ul></ul><ul><ul><li>This simplifies modeling (a key aspect of the object-oriented paradigm) </li></ul></ul><ul><li>Well-designed objects are independent units </li></ul><ul><ul><li>Everything that relates to the real-world object being modeled is in the object — encapsulation </li></ul></ul><ul><ul><li>Communication is by sending messages </li></ul></ul><ul><ul><li>This independence is enhanced by responsibility-driven design (see later) </li></ul></ul><ul><li>A classical product conceptually consists of a single unit (although it is implemented as a set of modules) </li></ul><ul><ul><li>The object-oriented paradigm reduces complexity because the product generally consists of independent units </li></ul></ul><ul><li>The object-oriented paradigm promotes reuse </li></ul><ul><ul><li>Objects are independent entities </li></ul></ul>
    43. 46. Classical Phases vs Object-Oriented Workflows <ul><li>There is no correspondence between phases and workflows </li></ul><ul><li>Classical paradigm </li></ul><ul><li>Requirements phase </li></ul><ul><li>Analysis (specification) phase </li></ul><ul><li>Design phase </li></ul><ul><li>Implementation phase </li></ul><ul><li>Post-delivery maintenance </li></ul><ul><li>Retirement </li></ul><ul><li>Object-Oriented paradigm </li></ul><ul><li>Requirements workflow </li></ul><ul><li>Object-Oriented Analysis workflow </li></ul><ul><li>Object-Oriented Design workflow </li></ul><ul><li>Object-Oriented Implementation workflow </li></ul><ul><li>Post-delivery maintenance </li></ul><ul><li>Retirement </li></ul>
    44. 47. Analysis/Design “Hump” <ul><li>Structured paradigm: </li></ul><ul><ul><li>There is a jolt between analysis (what) and design (how) </li></ul></ul><ul><li>Object-oriented paradigm: </li></ul><ul><ul><li>Objects enter from the very beginning </li></ul></ul><ul><li>In the classical paradigm </li></ul><ul><ul><li>Classical analysis </li></ul></ul><ul><ul><ul><li>Determine what has to be done </li></ul></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><ul><li>Determine how to do it </li></ul></ul></ul><ul><ul><ul><li>Architectural design — determine the modules </li></ul></ul></ul><ul><ul><ul><li>Detailed design — design each module </li></ul></ul></ul>
    45. 48. Removing the “Hump” <ul><li>In the object-oriented paradigm </li></ul><ul><ul><li>Object-oriented analysis </li></ul></ul><ul><ul><ul><li>Determine what has to be done </li></ul></ul></ul><ul><ul><ul><li>Determine the objects </li></ul></ul></ul><ul><ul><li>Object-oriented design </li></ul></ul><ul><ul><ul><li>Determine how to do it </li></ul></ul></ul><ul><ul><ul><li>Design the objects </li></ul></ul></ul><ul><li>The difference between the two paradigms is shown on the next slide </li></ul>
    46. 49. In More Detail <ul><li>Objects enter here </li></ul><ul><li>Modules (objects) are introduced as early as the object-oriented analysis workflow </li></ul><ul><ul><li>This ensures a smooth transition from the analysis workflow to the design workflow </li></ul></ul><ul><li>The objects are then coded during the implementation workflow </li></ul><ul><ul><li>Again, the transition is smooth </li></ul></ul>  Figure 1.9 Figure 1.8 <ul><li>Classical paradigm </li></ul><ul><li>Analysis (specification) phase </li></ul><ul><ul><li>Determine what the product is to do </li></ul></ul><ul><li>Design phase </li></ul><ul><ul><li>Architectural design </li></ul></ul><ul><ul><li>Detailed design </li></ul></ul><ul><li>Implementation phase </li></ul><ul><ul><li>Code the modules in an appropriate programming language. </li></ul></ul><ul><ul><li>Integrate </li></ul></ul><ul><li>Object-Oriented paradigm </li></ul><ul><li>Object-Oriented Analysis workflow </li></ul><ul><ul><li>Determine what the product is to do </li></ul></ul><ul><ul><li>Extract the classes </li></ul></ul><ul><li>Object-Oriented Design workflow </li></ul><ul><ul><li>Detailed design </li></ul></ul><ul><li>Object-Oriented Implementation workflow </li></ul><ul><ul><li>Code the modules in an appropriate OO programming language. </li></ul></ul><ul><ul><li>Integrate </li></ul></ul>
    47. 50. 1.10 The Object-Oriented Paradigm in Perspective <ul><li>The object-oriented paradigm has to be used correctly </li></ul><ul><ul><li>All paradigms are easy to misuse </li></ul></ul><ul><li>When used correctly, the object-oriented paradigm can solve some (but not all) of the problems of the classical paradigm </li></ul><ul><li>The object-oriented paradigm has problems of its own </li></ul><ul><li>The object-oriented paradigm is the best alternative available today </li></ul><ul><ul><li>However, it is certain to be superceded by something better in the future </li></ul></ul>
    48. 51. 1.11 Terminology <ul><li>Client, developer, user </li></ul><ul><li>Internal software </li></ul><ul><li>Contract software </li></ul><ul><li>Commercial off-the-shelf (COTS) software </li></ul><ul><li>Open-source software </li></ul><ul><ul><li>Linus’s Law </li></ul></ul><ul><li>Software </li></ul><ul><li>Program, system, product  </li></ul><ul><li>Methodology, paradigm </li></ul><ul><ul><li>Object-oriented paradigm </li></ul></ul><ul><ul><li>Classical (traditional) paradigm </li></ul></ul><ul><li>Technique </li></ul>
    49. 52. Terminology (contd) <ul><li>Mistake, fault, failure, error </li></ul><ul><li>Defect </li></ul><ul><li>Bug  </li></ul><ul><ul><li>“ A bug  crept into the code” </li></ul></ul><ul><ul><ul><li>instead of </li></ul></ul></ul><ul><ul><li>“ I made a mistake” </li></ul></ul>
    50. 53. Object-Oriented Terminology <ul><li>Data component of an object </li></ul><ul><ul><li>State variable </li></ul></ul><ul><ul><li>Instance variable (Java) </li></ul></ul><ul><ul><li>Field (C++) </li></ul></ul><ul><ul><li>Attribute (generic) </li></ul></ul><ul><li>Action component of an object </li></ul><ul><ul><li>Member function (C++) </li></ul></ul><ul><ul><li>Method (generic) </li></ul></ul><ul><li>C++: A member is either an </li></ul><ul><ul><li>Attribute (“field”), or a </li></ul></ul><ul><ul><li>Method (“member function”) </li></ul></ul><ul><li>Java: A field is either an </li></ul><ul><ul><li>Attribute (“instance variable”), or a </li></ul></ul><ul><ul><li>Method </li></ul></ul>
    51. 54. 1.12 Ethical Issues <ul><li>There is a code of ethics for Software Engineers. </li></ul><ul><li>What is an example of where such a code might be necessary? </li></ul><ul><li>IEEE-CS ACM Software Engineering Code of Ethics and Professional Practice </li></ul><ul><li>http://www.acm.org/constitution/code.html </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×