1. Software Construction (SE-301) Asst. Prof. Shahbaz Ahmed Dept. of Computer Science and Software Engineering International Islamic University Islamabad A Lecture Series to BS Software Engineering Spring 2016 DCS & SE, FBAS, IIUI 1

2. Words of Wisdom We must understand that life is difficult, if we know and accept it, it is no longer difficult Do men think that they will be left alone on saying “We believe” and that they will not be tested? We did test those before them and Allah will certainly know those who are true from those who are false. Al-Qur’an (29:2-3) 2

3. Objectives of the Lectures Appreciate the Fundamentals of Software Engineering 3

4. Assumptions for this Class Assumption: – You have taken Beneficial but not necessary: – You have had practical experience with software system – You have already participated in a software project – You have experienced major problems while developing software systems. 4

5. Grading Criteria – As per university policy 5

6. Focus: Acquire Technical Knowledge Different methodologies (“philosophies”) to model and develop software systems Different modeling notations Different modeling methods Different software lifecycle models (empirical control models, defined control models) Different testing techniques (eg. vertical testing, horizontal testing) Rationale Management Release and Configuration Management 6

7. Acquire Managerial Knowledge Learn the basics of software project management Understand how to manage with a software lifecycle Be able to capture software development knowledge (Rationale Management) Manage change: Configuration Management Learn the basic methodologies – Traditional software development – Agile methods. 7

8. Outline of Today’s Lecture The development challenge Dealing with change Concepts: Abstraction, Modeling, Hierarchy Methodologies 8

9. Can you develop this system? 9

10. WHAT IS SOFTWARE ENGINEERING? Where is its place in broad area of computing? 10

11. Solutions Theory Knowledge Spectrum Science Engineering Science Engineering Design Engineering Technology Production Installation The study that focuses on materials, processes and material actions Application of engineering science knowledge to improve the quality of life. We are now being creative with our knowledge The creation of artifacts and systems to meet people's needs – construction, manufacturing 11

12. A Computing Spectrum Science Engineering Science Engineering Design Engineering Technology Production Installation Solutions Theory Algorithms Information theory Computability theory System Software Computer Architecture Information storage System Administration End-user Support Analysis & Design Methods Design Process Measurements Development Environment Implementation Standards 12

13. Computing Professions Science Engineering Science Engineering Design Engineering Technology Production Installation Solutions Theory Creates New Infrastructure Computer Scientist Software Engineer Creates new applications applying engineering principles and CS best practices Information Technologist Provides end-user solutions 13

14. LETS REFER TO SEBOK DOCUMENT 14

15. SO! WHAT IS SOFTWARE ENGINEERING Rather ! What is a Software ???? 15

16. WHAT IS SOFTWARE ENGINEERING ? The IEEE Computer Society defines software engineering as: 1.The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. 2.The study of approaches as in (1). 16

17. WHAT IS A RECOGNIZED PROFESSION For software engineering to be fully known as a legitimate engineering discipline and a recognized profession, consensus on a core body of knowledge is imperative. – This fact is well illustrated by Starr when he defines what can be considered a legitimate discipline and a recognized profession. In his Pulitzer Prize-winning book on the history of the medical profession in the USA, he states that: “The legitimization of professional authority involves three distinctive claims: – First, that the knowledge and competence of the professional have been validated by a community of his or her peers; – Second, that this consensually validated knowledge rests on rational, scientific grounds; – Third, that the professional’s judgment and advice are oriented toward a set of substantive values, such as health. 17

18. CHARACTERISTICS OF A PROFESSION Gary Ford and Norman Gibbs studied several recognized professions, including medicine, law, engineering, and accounting. They concluded that an engineering profession is characterized by several components: – An initial professional education in a curriculum validated by society through accreditation – Registration of fitness to practice via voluntary certification or mandatory licensing – Specialized skill development and continuing professional education – Communal support via a professional society – A commitment to norms of conduct often prescribed in a code of ethics 18

19. IS SOFTWARE ENGINEERING A DISTINCT PROFESSION What are its knowledge areas 19

20. SE Knowledge Areas SOFTWARE REQUIREMENTS KA SOFTWARE DESIGN KA SOFTWARE CONSTRUCTION KA SOFTWARE TESTING KA SOFTWARE MAINTENANCE KA SOFTWARE CONFIGURATION MANAGEMENT KA SOFTWARE ENGINEERING MANAGEMENT KA SOFTWARE ENGINEERING PROCESS KA SOFTWARE ENGINEERING TOOLS AND METHODS KA SOFTWARE QUALITY KA 20

21. WHY ALL THE FUSS ABOUT S/W ENGG. Why are there so many problems still persisting???? 21

22. Nature of Software (F.P. Brooks) The essence of a software entity is a construct of interlocking concepts (conceptual construct) I believe that hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems F. P. Brooks 22

23. SOFTWARE Lets talk about software first 23

24. Essence of Software Complexity Conformity Changeability Invisibility 24

25. Did You Get my Point After Discussion 25

26. ENGINEERING Now lest have a look at engineering 26

27. Engineering Derived from old French engin = skill, which stems from Latin ingenium = ability to invent, brilliance, genius The word was created in the 16th century and originally described a profession that we would probably call an artistic inventor ("Encyclopedia" by The Software Toolworks, 1991) Engineering is applied science Engineering is the application of science for practical purposes Engineers put theory into practice. 27

28. Engineering (cont…) ABET, USA – The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize, economically, the material and forces of nature for the benefit of mankind The profession of or work performed by an engineer. Engineering involves the knowledge of the mathematical and natural sciences (biological and physical) gained by study, experience, and practice that are applied with judgment and creativity to develop ways to utilize the materials and forces of nature for the benefit of mankind (International Technology Education Association). 28

29. Engineering (cont…) Engineering methods put a lot of emphasis on planning before you build Design, Plan and then Construct Construction is much bigger in both cost and time than design and planning – 80-90% What is the proportion in Software Engineering? – 10-30% – Software construction is so cheap as to be free – All effort is of design 29

30. Engineering Software Design requires creative and talented people Creative processes are not easily planned, and so predictability may well be an impossible target – Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan This raises an important question about the nature of design in software compared to its role in other branches of engineering We should be very wary of the traditional engineering metaphor for building software. It's a different kind of activity and requires a different process (Martin Fowler, The New methodology) 30

31. Can you develop this system? 31

32. Can you develop this system? 32

33. Can you develop this system? 33

34. Why is Software Development difficult? The problem is usually ambiguous The requirements are usually unclear and changing when they become clearer The problem domain (called application domain) is complex, and so is the solution domain The development process is difficult to manage Software offers extreme flexibility Software is a discrete system – Continuous systems have no hidden surprises – Discrete systems can have hidden surprises! (Parnas) 34

35. Software Development is more than just Writing Code It is problem solving – Understanding a problem – Proposing a solution and plan – Engineering a system based on the proposed solution using a good design It is about dealing with complexity – Creating abstractions and models – Notations for abstractions It is knowledge management – Elicitation, analysis, design, validation of the system and the solution process It is rationale management – Making the design and development decisions explicit to all stakeholders involved. 35

36. Can we not use the Scientific Method? Not exactly, we need ideas and hypotheses – The scientific method, unfortunately, has never quite gotten around to saying exactly where to pick up these hypotheses. The traditional scientific method has always been at the very best, 20-20 hindsight – It's good for seeing where you've been. It's good for testing of what you think you know – But it can't tell you where you should to go Creativity, originality, inventiveness, intuition, imagination – "unstuckness," in other words – are completely outside the domain of the scientific method – Robert Pirsig, Zen and the Art of Motorcycle Maintenance, p. 251, Bantam Books, 1984. 36

37. Techniques, Methodologies and Tools Techniques: – Formal procedures for producing results using some well-defined notation Methodologies: – Collection of techniques applied across software development and unified by a philosophical approach Tools: – Instruments or automated systems to accomplish a technique – Interactive Development Environment (IDE) – Computer Aided Software Engineering (CASE) 37

38. Computer Science vs. Engineering Computer Scientist – Assumes techniques and tools have to be developed. – Proves theorems about algorithms, designs languages, defines knowledge representation schemes – Has infinite time… Engineer – Develops a solution for a problem formulated by a client – Uses computers & languages, techniques and tools Software Engineer – Works in multiple application domains – Has only 3 months... – …while changes occurs in the problem formulation (requirements) and also in the available technology. 38

39. Challenge: Dealing with complexity and change Software Engineering is a collection of techniques, methodologies and tools that help with the production of A high quality software system developed with a given budget before a given deadline while change occurs Software Engineering: A Working Definition 39

40. Software Engineering: A Problem Solving Activity Analysis: – Understand the nature of the problem and break the problem into pieces Synthesis: – Put the pieces together into a large structure For problem solving we use techniques, methodologies and tools. 40

41. What is an Engineering System? Engineering system = capability for the development of systems, hardware, or software Components: – People – Process – Technology – Knowledge Interfaces: – Internal (among components) – External (to stakeholders and customers) 41

42. 42 Primary Relationship Diagram People Process Technology Knowledge Engineering System (Components of an engineering system)

43. 43 Engineering System Capability Resources and Requirements Systems, Software, & Hardware Products ….Time….

44. 44 Why Software Engineering? Software development is hard ! Important to distinguish “easy” systems (one developer, one user, experimental use only) from “hard” systems (multiple developers, multiple users, products) Experience with “easy” systems is misleading – One person techniques do not scale up Analogy with bridge building: – Over a stream = easy, one person job – Over River Severn … ? ( the techniques do not scale)

45. 45 Requirements Software Limitations of Non-engineered Software

46. 46 Why are software systems so complex? The problem domain is difficult The development process is very difficult to manage Software offers extreme flexibility Software is a discrete system – Continuous systems have no hidden surprises (Parnas) – Discrete systems have!

47. 47 Dealing with Complexity 1.Abstraction 2.Decomposition 3.Hierarchy

48. Software Engineering-IShahbaz Ahmed48 What is this?

49. 49 1. Abstraction Inherent human limitation to deal with complexity – The 7 +- 2 phenomena Chunking: Group collection of objects Ignore unessential details: => Models

50. 50 Models are used to provide abstractions System Model: – Object Model: What is the structure of the system? What are the objects and how are they related? – Functional model: What are the functions of the system? How is data flowing through the system? – Dynamic model: How does the system react to external events? How is the event flow in the system ? Task Model: – PERT Chart: What are the dependencies between the tasks? – Schedule: How can this be done within the time limit? – Org Chart: What are the roles in the project or organization? Issues Model: – What are the open and closed issues? What constraints were posed by the client? What resolutions were made?

51. 51 Interdependencies of the Models System Model (Structure, Functionality, Dynamic Behavior) Issue Model (Proposals, Arguments, Resolutions) Task Model (Organization, Activities Schedule)

52. 52 Issue-Modeling Issue: What is the Center of the Universe? Proposal1: The earth! Proposal2: The sun ! Pro: Copernicus says so. Pro: Aristotle says so. Pro: Change will disturb the people. Con: Jupiter’s moons rotate around Jupiter, not around Earth. Resolution (1615): The church decides proposal 1 is right Resolution (1998): The church declares proposal 1 was wrong

53. 53 Which decomposition is the right one? 2. Decomposition A technique used to master complexity (“divide and conquer”) Functional decomposition – The system is decomposed into modules – Each module is a major processing step (function) in the application domain – Modules can be decomposed into smaller modules Object-oriented decomposition – The system is decomposed into classes (“objects”) – Each class is a major abstraction in the application domain – Classes can be decomposed into smaller classes

54. 54 What is This?

55. 55 Model of an Eskimo Eskimo Size Dress() Smile() Sleep() Shoe Size Color Type Wear() * Coat Size Color Type Wear()

56. 56 Iterative Modeling then leads to.... Eskimo Size Dress() Smile() Sleep() Cave Lighting Enter() Leave() lives in but is it the right model? Entrance * Outside Temperature Light Season Hunt() Organize() moves around Windhole Diameter MainEntrance Size

57. 57 Alternative Model: The Head of an Indian Indian Hair Dress() Smile() Sleep() Mouth NrOfTeeths Size open() speak() * Ear Size listen() Face Nose smile() close_eye()

58. 58 Class Identification Class identification is crucial to object-oriented modeling Basic assumption: 1.We can find the classes for a new software system: We call this Greenfield Engineering 2.We can identify the classes in an existing system: We call this Reengineering 3.We can create a class-based interface to any system: We call this Interface Engineering Why can we do this? Philosophy, science, experimental evidence What are the limitations? Depending on the purpose of the system different objects might be found – How can we identify the purpose of a system?

59. 59 What is this Thing?

60. 60 Modeling a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry()

61. 61 A new Use for a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry() SitOnIt()

62. 62 Questions Why did we model the thing as “Briefcase”? Why did we not model it as a chair? What do we do if the SitOnIt() operation is the most frequently used operation? The briefcase is only used for sitting on it. It is never opened nor closed. – Is it a “Chair”or a “Briefcase”? How long shall we live with our modeling mistake?

63. 63 3. Hierarchy We got abstractions and decomposition – This leads us to chunks (classes, objects) which we view with object model Another way to deal with complexity is to provide simple relationships between the chunks One of the most important relationships is hierarchy 2 important hierarchies – "Part of" hierarchy – "Is-kind-of" hierarchy

64. 64 Part of Hierarchy Computer I/O Devices CPU Memory Cache ALU Program Counter

65. 65 Is-Kind-of Hierarchy (Taxonomy) Cell Muscle Cell Blood Cell Nerve Cell Striate Smooth RedWhite Cortical Pyramidal

66. 66 So where are we right now? Three ways to deal with complexity: – Abstraction – Decomposition – Hierarchy Object-oriented decomposition is a good methodology – Unfortunately, depending on the purpose of the system, different objects can be found How can we do it right? – Many different possibilities – Our current approach: Start with a description of the functionality (Use case model), then proceed to the object model – This leads us to the software lifecycle

67. 67 And oh yes one more thing Always remember the law of diminishing returns. – “Your tea will get sweater up to a certain level only and the excess sugar will produce no effect” – Same is the case with software engineering Moral – Efficient resource Utilization