Software Engineering- A Methodology for Reliable Software | DataHour by Vineeth Paleri

Key Takeaways

yeah welcome the audience uh this uh talk is based on the observation that the discipline software engineering is yet to mature mature in the sense that like any other engineering discipline software engineering I expect should give its product that is the software with a guarantee let me just give an idea regarding the content of the talk so brief introduction followed by some principles and techniques which we use as far as programming is concerned and the core of the talk is the methodology for programming and the large and software engineering through which we try to achieve Reliable Software and we will just mention about the classical faces in software development that is software testing and maintenance and will conclude so at the beginning let me make it uh very clear what exactly the goal of the talk is it's Reliable Software maybe I should add saying that this is an ongoing experiment we have been offering a course called foundations of programming in our Institution for around for the last 10 years with programming were reliability or correctness is the ultimate goal with that let's get to the introduction if you see e-programming even today is more of an art and most people do programming with little direction as as to the principal involved as far as Reliable Software is concerned note that an art you can see is uh a learning artists more of watching others perform and maybe skills acquired by habit what this uh talk is essentially stressing is that for Reliable programs programming requires first of all conscious application of principles yes there are fundamental principles and we need that conscious application of principles basically to have the reliability and then you must have a systematic approach to the development so we talk about the principles and we talk about the systematic approach to development ultimately saying that or rather this talk essentially says that programming or finally the software engineering is a science not an art okay note that there can be debates on that but this talk is essentially saying it's science we observe that learning programming many a Time ends up in a in learning a programming language many times so I mean one of the experience which I have is that when we when I look at the CV of graduates even we take a computer science graduates Under The Heading programming skills most of the time observe that what is really put us the programming language is not programming so there are no principles in programming that is explicitly put so the point is that when we have a course on programming what should we teach the programming languages may come and go but ultimately what is going to remain is programming so we should be talking about programming not just the tool that's a programming language so in that sense programming language involves orderly thinking for example separation of concerns is the key principle which we use basically to order that thinking orderly thinking through separation of concerns you can talk about many problem solving ideas and the key point which we stress is the modular design when you have complex problems divided into smaller pieces or modules sort of and ultimately ability to tackle complexity especially when we have complex problems and in in another way ultimately we are stressing on Simplicity because we say that Simplicity is a pre-requisite for reliability now when we come to the methodology which we adopt we actually adopted in our Institution we say that we have taken or rather we have three steps explicitly as far as the programming development process concern starting with specification followed by Design followed by encoding so we'll be talking about every stage which is basically the talk on that is the methodology the methodology essentially has three steps again uh in our course which we have been doing it as an experiment as I said we essentially stress the specification in design and in fact we do the specification and design in the class and only after the student is confident about the design we ask the student to go to the coding stage in the laboratory so we'll take up each of these stages slightly in detail let's look at the specification part so that starts with uh problem understanding meaning before attempting to solve a problem Nick absolutely sure what what the problem is you you can see that many a Time the problem specification or problem definition can be can be confusing so we must be very careful so there must be enough attempt basically in the understanding problem and it is observed that many a Time the problems understanding and specification is grossly under underestimated the importance of that is grossly as underestimated and getting into a lot of problems later I mean asking for maintenance and also software engineering some of the uh the observations are 50 of the problems are simply arise basically because of not spending the amount of time required for problem understanding and specification now we can observe that the specification there are some requirements specification should be for example unambiguous it should be non-contradictory and finally it should be complete let's go into each one of them so if you see the specific if you find the specification is sufficiently ambiguous note that any program will satisfy so this I mean if you want a single solution the specification has to be precise most of the time your problem is given in such a manner that it is ambiguous and hence the problem and there can be possibility as far as the specifications uh many many of the points in the specifications contradicts not one of them contract exhibits the other so if that happens you know that no program will satisfy that if you have contradictory requirements and the completeness issue the more the specification is complete the less the maintenance many times in software engineering I feel that in the industry the main problem the complaint as far as the problem that we are addressing reliability is that we don't have a complete specification or the client will not be in a position to give the specification completely at the beginning but but theoretically you can say that the more the specification is complete the less the maintenance and we say that it we should try to have the specification even extrapolated so that we can actually incorporate that into the design so that when the client really asks for a change we don't have to have ultimately a design change design change is going to be uh really costly and in this context maybe I can uh maybe point out one of my experience as far as the specification stage is concerned that's around 15 years back I don't know you know there is what is called all India engineering entrance examination uh counseling software so during that development we 14 uh participants from 14 and I mean Regional engineering colleges at that time it was 15 years back assembled in uh a regional engineering College in Alhambra and it was surprising even to me that we spent for two full days 14 people and the aim was basically to have the specification the national informatics Center came with their draft we debated on two days and finally got to that and the outcome according to me is that that software ran without much problems and let's let's take an example to understand that kind of a problem understanding and specification let's look at this small very simple problem let's say divide two integers to get the quotient and remainder and for the sake of argument let me say that we are saying do it by repeated subtraction note that this itself can be ambiguous even a very simple problem statement like this because uh uh I mean I said just integers and whether the negative value is considered or not I mean all those issues can come and you have to be very precise as far as the understanding is concerned so whenever a problem statement is given we have to understand and put it as a specification with the three conditions we have said so that we have no problem as far as the final product is concerned so we use an input output format as far as the specification is concerned and as far as this problem is concerned we will go like this as for the input is concerned let me for the timing even though originally it was said as integer in the specification let me take the problem as a dividend and divisor the two inputs they are from natural numbers and I'm not considering uh negative values with an assumption that I can add the sign later with an additional function sort of so dividend device and I say specify that I have natural numbers they are natural numbers and qualified further dividend is greater than or equal to zero and note that I'm saying divisor is greater than m0 not greater than or equal to zero knowing very well that I won't be able to divide n number by zero so that issue of division by zero is taken care of in the specification itself and if the user gives a 0 as the device immediately we can Flash an error so in the sense that we have to uh have the I'll say program in such a manner that any any ambiguous or rather unsure the possibility is captured by it without getting the program stuck or getting into the loop or nothing like that should happen as well as the final Reliable Software is concerned so this is the input and similarly we can talk about the output that the quotient and the remainder you can see that the quotient is greater than or equal to zero and remainder we say it is greater than or equal to 0 and it must be less than divisor note that if it is equal to less than or equal to you can you can once more subtract it so it is the remainder less than divisor and ultimately the input and output has to satisfy this satisfy this condition that is dividend is equal to cosine multiplied by demison plus remainder note that we have adopted such a uh uh I'll say simple mechanism basically to specify the problem input output sort of you can go even with English language but you'll have to be very careful note that natural language is inherently ambiguous so a judicious use of English is required in the problem specification so that's why we did not write in English we thought maybe we can write it something like this and you can go to the final extreme or formal specification even by predicate calculus which is considered to be I mean with which you can actually have really formal and ambiguous uh specification with that kind of a specification let's go to the design stage now so so we as we said at the beginning there are principles for uh methodology so one of the design principles are I'll say the main design principle which we use as far as the methodology our methodology is concerned is suppression of concerns so in this context I can take dijkstra's code says that separation of concerns is the only available technique for effectively ordering one's thoughts note that we said earlier the principles involves orderly thinking and that is concrete concretized by how do we do that or order I mean ordering of thinking you can use this principle of separation or concerns Whenever there is a problem where with more than one concern right you try you try to try to separate it and deal it in I mean independently in a sense so the best thing which I can quote in this context is that let's say when we talk about an undergraduate program in computer science we have the programming concerns of correctness efficiency maintainability all those things so you can have a course like foundations of programming we say that the concerns there is only correctness and we tell that efficiency aspect is considered in another course like data structures and algorithms and other aspects like maintainability in a full-fledged software engineering course etc etc so separation of concern is the key principle which which is uh which we use as far as this methodology is concerned foreign principle is the classical one we may normally see that it is by dividing the problem the smaller pieces here I can say that into modules so that's the generic term which we use here and I'll say that there's only one way to deal with complex problems that's basically divided into smaller modules any complex problem trying to deal it in complex that's going to be difficult or rather I mean you will get into trouble so the first thing is try to divide into smaller modules I mean that but but I we feel that that's not sufficient and we added this adjective divided into smaller independent modules we feel that this is a very important point that is independent modules is a key in the sense that when we talk about the complexity of software development I don't have a clear answer regarding that whether it is linear in with respect to the size of the code it is quadratic or it goes exponential as the size increases but the crucial Point here is that if we have independent modules I'll just post the question and say that can't the software development process complexity is linear if they are independent if it is not independent definitely it's not going to be linear so the key point is divided into smaller independent modules now let's get to get to when we talk about the modular design the modules can be further from there you can come to two further principles which are proceed obstruction and data abstraction so whenever the computation note that whenever we talk about computation you have fundamentally two parts that is you have the data and you have the computation you have data and computation and whenever the computation is complex we use procedural abstraction and whenever we have complex data we use uh that are obstruction so note that these are two fundamental principles as far as I mean we use as far as our methodology especially when the program becomes larger the fundamental principles for small programs uh remains but as the program gets larger you divide into modules and the modules can be in terms of functions or procedures as we call which is basically personal abstraction or data abstraction for example you can say programming languages gives us array as a data abstraction and you can build your own abstractions so let's uh come to Brazil abstraction a little bit in detail we say the proceed abstraction separates the concern of how a procedure would be used from the concern of how the procedure would be implemented so the key point is that it separates the concern of use and implementation uh a typical example of which I can quote is let's say print of function print function so when the user uses it he or she need not know how exactly it is implemented so I mean use is separated from the implementation but somebody has to implement that but as always a user of a programming language is concerned he has to remain how to use it print definite share how to write with the syntax and Associated components whatever it is how exactly it is implemented is not as concerned so the the function printf is abstracted you're raising the level of of that function and you need to know only how to use it proceed abstraction separates the concerns of use from the implementation details again let me take an example to just to have a feel of what exactly this procedural abstract now how exactly it's a powerful mechanism in the hands of a programmer let me take a small problem again for the sake of explaining this uh concept let's say that you are given a list of students and the throttle marks in a semester list of students and the total marks in a semester and you are asked to write a program to compute the percentage of students in the class having marks above the class average so list of students and total marks are given we have to find the percentage students in the class having marks above average note that now we say that we have we essentially uh understand the problem and I'm not explicitly writing the specification the input is list of students and the total mods output is percentage of students above class average now we'll have to see how exactly this can be handled note that we set it I mean you can have processing abstraction and we say that you can go to go to sort of a modular design in terms of identifying the sub task in the problem it may look to some problems may be trivial but this is for elaboration or as an example so you can see first I mean percentage above average is our final goal and the way in which I can read this diagram is that suppose you have a function which gives me the above average count and the number of students then I can compute percentage above average so it sort of uh dividing the problem into smaller pieces as we go down and we write it as a tree form you may even call it in I mean in the literature you may find that the stepwise refinement the the original problem that is percentage above average is refined to some problems finding above average count and number of students and the second thing is that your goal average count can be found once you know average if you know average you can find above average count from of course the list of students that's given similarly average can be found if you know the sum of the marks and also the number of students so there is a very systematic way of dividing the problem into smaller piece and we call it a subtask diagram and it is a Brazil abstraction and here is a diagram which essentially raises the level at which Your Design goes may be similar to those who are in object oriented program you know that uh fundamentally the talk level design can be a class diagram identifying the classes and interactions and from there you go down to lower level of design maybe in this context I can uh stress the importance of that kind of a high level design sort of it helps you to have a grip on the entire problem this is a very small problem when suppose you have a very complex problem getting a grip is not at all an easy thing and in this context let me quote I mean there is there is an article titled Emperors all clothes by a whole car I mean Turing Award winner and there was a project Elliott 503 Mark II and the project has to be abandoned basically because he says that I mean let me quote the goals which we have attempted have proved to be far beyond our grip and he also says that in the process of abandoning the project 30 man years of programming effort was wasted so so it's not an easy job whenever a problem is complex to get a grip so we are essentially trying to have design diagrams as higher level as possible finally you get a grip and this is one of the possibly subtract diagram using modular design sort of and and now we can we we essentially write the main function using those sub functions note that when we have the sub functions we use the specification of the sub functions we don't have the code right now we only have the specifications and that's what exactly personal abstraction is we have specifications we know what it does but we don't know how exactly it is implemented using the specifications we write the main functions okay so here is the main function for our problem it is basically Computing percentage note that I'm using scheme as a vehicle because we used it as I mean because it's a simplest language where it has only one data structure that is list and the features are also very very small and students learn that in let's say two sessions sort of themselves we don't teach them sort of I mean we give the manual so here percentage above average bold in bold that is the task subtask that's the main problem and problem understanding stage we find that in fact I mean the input that is given list of marks and students we don't need the students names as far as this problem is concerned so from the input list the user get list of mocks function and we put it in list of marks okay so we remove unwanted things in the beginning so that we are not bogged down with those unwanted details so we get the list of marks and then once we get the list of months I mean I can find the average with the list of marks as the input note that I'm taking average at the higher level I could have gone down to uh sum and uh the length sort of but in order to I mean make it simpler so I'm saying average is found in I mean using the input list of marks and above average count is done or got or you calculate that from the average and the list of marks you can find above average count and once you have the above average count and the length which you can find from the given the list of marks you can find the percentage by dividing it and multiplying by hundred so note that this problem we say that my writing this my main function using the subtask I mean we have identified I mean we have a grip I mean I repeat that word grip I mean which for a large project it's not an easy job so we have this methodology using protocol abstraction identifying the subtask writing the specification not the code at this point of time and using the specification to write the main function so that you have the full grip of the project in essence now let's come to data abstraction the second uh mechanism uh and note again that abstraction many times people have a feeling that is something complicated but the the main main reason why we go for abstraction is to create a higher level uh where things gets easier simpler the even though the word the may look I mean a little bit complicated the aim ultimately to is to simplify know that and here again similar to the personal abstraction note that that abstraction is a methodology that enables us to isolate I mean basically the use of that data from its implementation use and implementation it isolates these two I mean uh possible tasks in a sense or rather you can say it abstracts the details of the implementation as far as the user is concerned so the you know uh course we create a data structure that have structures using basically Constructors and selectors and we ask the students to write all that are abstracts and traditional and abstraction like stack queues um I mean trees and whatnot okay I mean this can almost be constructed using this I mean concept so that you can you can talk about finally creating a dietary Library similar to the Brazil Library you can talk about data Library which can you can use later as a simple example I mean typical databases you can say that it is built I mean that's the highest level of abstraction and that is built from records their records so you can say every record is built from I have taken it as prior you can talk about a typo containing many many fields whatever it is and finally each each pair is implemented as a list let's say so you create that kind of an abstraction and then whenever you deal with uh some some processing you stick to that layer of abstraction so that you can you can you can you don't complicate the things you don't break the barrier as far as the abstraction is concerned and you can do your task at that level that is you have created at a level uh levels so that you don't see the wall layers and gets the gets uh the things complicated sort of so you create that kind of a data level abstraction you know from the methodology finally the road the goal of the the talk is basically talking about the reliability so let me come to that aspect and so you can say that ultimately we allowed to prove that our program whatever program we write is correct so we say the proof proof of correctness of the program which we finally write I mean as I said software engineering if it has to be a mature discipline finally we have to have software with a guarantee so that's what actually we are talking about proof of correctness and the methodology which we adopt it's basically telling that proof of correctness goes hand in hand with program development note that the traditional approach can be you write the program and then debug it no this methodology very clearly tells that proof of correctness goes hand in hand with the development so in order to elaborate that proof of correctness goes hand in hand let's talk about the methodology a very systematic approach method I mean method through which we finally when we at the end of the development we have a high confidence if not 100 guarantee regarding the correctness of the program so let's take the same example which you have seen earlier that is uh division of two numbers you have dividend greater than or equal to zero and device are greater than zero that is the input specification which you are written similarly in the output specification caution greater than zero remainder greater than or equal to zero and less than device satisfying the invariant dividend is equal to quotient multiplied by Design uh divisor plus remained now we say that you can even say that given the specification these sort of derive the program from the specification now we said very clearly that it is by repeated subtraction so that clearly tells us in the design that I must have a loop sort of so I introduced that so this is the syntax of the loop where you have a condition and a body and if the condition is satisfied semantic now this is a syntax semantics is if the condition is satisfied the body is executed so the construct is perfectly clear now there are two aspects now I have to confirmate I we take separation of the concerns and then we look at conditional body each one one at a time so we look at the condition now you know that the loop body has to be executed when the dividend is greater than the device so then you can subtract otherwise you can accept so with that observation I can now put the condition so I put the condition as dividend greater than or equal to device only then I can subtract I can go inside the body and do the subtraction it will keep on going until this condition is not satisfied that is basically dividend becomes less than the voice of the loop will terminate so I have designed the condition and made also sure that that is the condition I need as far as the loop is concerned now I can say that I have introduced these two variables so let me finish up those things that's required so I'll say read the dividend and divisor from the user and we have what is called an input validation and that is validation is done with respect to the input specification note that if you don't have the specification you won't be able to validate so we are using that specification to input validate checking that dividend is greater than or equal to zero and divisor is greater than zero if this condition is violated immediately an error message is giving a given to the user telling that you have violation of the specification you can go very precisely which which input and what exactly happens now now we can go to the body and once you the condition is satisfied we have already seen that it is repeated subtraction so we subtract the divisor from dividend and once you know that you know that the quotient can be incremented so the body contains two updates dividend is updated by subtracting and the quotient is incremented by one so there is going to be an assignment these two that is the variables remained in advance I mean caution so maybe when you introduce you have to uh initialize those values the quotient initially is zero and it is incremented as we subtract and the remainder is initialized with the dividend the original value so that's what actually we do reminder is equal to Dividend quotient equal to zero that's the initialization note that we have changed the I mean dividend to remain there because you can see that remainder is what is keeping on changing so it's better not to use the dividend as the name there so initialize the dividend put the dividend to remainder and just tell inside the body on the loop that use the remainder there so that's a better strategy startup so note that change and now you can put the content remainder is equal to remainder minus divisor quotient is equal to question one that's it that's the that's the body so note that we are going step by step making sure that this is what has to be done and we have the high confidence finally you can maybe print the things right so this is the systematic way to develop and finally this is the program and we can now ask in fact in the in the course we ask the student is the program correct so the point is that with the whole explanation of every stage and explanation it is I mean what we are done for example the condition we have put is correct etc etc every step finally the student has to feel that it is correct sort of and we even ask do you really need to execute this one initially I mean the the hand The Hangover of executing slowly they finally say that okay through this process which we explained I feel that it is correct for any input it should give the correct answer that's the level of confidence finally the aim as far as the from the students is concerned so is the program correct okay ultimately with this methodology we feel that we can come to maybe it is a small program we are taken but remember any big program is divided into smaller programs and you can have this methodology to systematically develop programs and have very high level of confidence as far as the correctness is concerned now maybe with respect to correctness may let me add there is another another aspect which any series programmer has to be concerned that is the proof of termination of a loop the concepts many times people I don't know we ask the students whether you have I mean uh proved that you're the loop you write it will terminate or not and the insist in this course any Loop you write you must prove its correctness otherwise we don't call you programmers so we have to tell some kind of a concept how exactly you can do so in this respect we have the concept of a well-founded set which is basically a set which contains no infinite decreasing chain sort of let's say natural numbers if you start from some number if you talk about the way it goes down I mean it keeps on reducing and you have the chain has to stop at zeros or off so we choose a well-founded set it can be it can be a natural number it can be a set whatever it is and you have a termination measure which is basically a function which maps The Machine status to an element in this set maybe let me explain the concept again proof of termination just uh maybe some more Loop but the concept I hope I mean this example we will convey that so let's take a loop this is the syntax the semantics we explained if the condition is true the body is executed and let's make a concrete example like uh you have I initialized to zero and the condition is if I less than zero you will go inside the body and I is incremented by one in the dot dot dot inside the body indicates that I is not changed okay that that is basically another important point if we take this one how exactly we use the concepts note that so I is initialized to zero we now observed that inside the loop I monotonically increases that's a keyword as far as termination is concerned monotonically increases it does not oscillate I goes from 0 to 1 to 2 Etc in each iteration It Is incremented by 1 that I mean implies I monotonically increases y1 implies I will reach 10 that implies Loop will terminate basically because the condition for termination is I mean I less than 10. so note that you can take any program and finally prove that it it will terminate and in fact this asks for a discipline in programming okay note that proving correctness Demands a discipline programming like structured programming for example in the sense that whenever you write let's say a loop I mean we say structured programming asks for single entry single exit so that I mean the whole analysis of a loop cannot be I mean is not cluttered otherwise it becomes difficult to understand analyze prove Etc structured programming then careful use of variables in the termination of the condition so note that whatever variables you are using in the termination condition if you clutter it with some other purposes then your your your I mean doomed as far as uh analyzing what exactly happens to that variable so careful use other variables and ultimately Simplicity Summit look for simple way to finally run the thing sonoff so in this context when I talk about a discipline programming we tell the students that no Global variables because it violates uh uh the fundamental principle of I'll say independence and if you if you have a loop and there is a go to outside or a global variable I mean you find it almost impossible to analyze it sort of so no Global variables no go to statements meaningful names to the variables etc etc so the discipline programming is a key thing to finally prove the crackers if you don't have this discipline write the loop somehow and later try to prove the termination it's definitely going to be difficult so you must have that simplicity so that finally it is easy to prove the correctness so with that design stage I mean two parts program when you talk about the correctness note that normally you'll have to talk about the termination of the program so fundamentally on the loops and then the correctness of the output so we'll have to prove that the program finally gives the correct output given the specified input sort of so that's that's what exactly we explained through a simple example so hope that simple example the the normal charge that comes in is that for a small program you can do it note that the what exactly we are trying to conveys the concept and we feel that it can be it can be scalable okay now let me just mention some of the some of the aspects in coding which we know that uh okay maybe again let me quote dijkstra he he says that the tools we are trying to use and the language of the notation we are trying to express or use to express or record our thoughts are the major factors determining what we can think or Express at all and telling that program into a programming language not in it so when we have the design normally we say that have the design in annotation or the language independent of the programming language in which ultimately you are going to have your program implemented so your design is independent of the programming language you can take the design to any programming language later ideally there can be of course limitations I mean for example suppose you have a functional style you'll have to use that sort of imperative style you have to use that but fundamentally the concept is that try to isolate Your Design from the implementation details of the programming language so in this respect maybe you can note that as a restricted language can hide the best algorithm from us example language without recursion for example Fortran 4 did not have recursion and you cannot have Elegant recursive Solutions that's available you know at that time in that language so a restricted language can hide the best algorithm from us and a restricted language can or limits our thought process let's say that the language without a construct for non-determinism in which normally normal programming ready programming languages does not give you let's say the syntax of a non-deterministic construct is something like this were it says you have conditioned action players what exactly don't determine some says is that if any of these conditions are satisfied you can have the corresponding action executed not it is sequential I mean you can you can any condition satisfied you can execute typical examples in an ATM where let's say you are asking for withdrawal of 1000 rupees note that if I mean it can be 10 hundred rupee notes or two 500 rupee notes so if the machine has two 500 rupee notes available it can dispose that if the machine has 10 100 rupee node it can dispose that so that's the way in which we write so the output can be non-deterministic but suppose you don't have this non-deterministic uh construct you have to have a sequential order like if this condition helps this condition else if this condition so that's putting an explicit order which is not really a necessary sort of and now coming to another aspect a cluttered language can hinder us from thinking clearly an example is consider consider your multiplication of two numbers and say the notation the language we use is normal Roman numerals rather than the decimal numbers try to multiply two large numbers represented in normally I mean Roman numerals and try to multiply it and compare it with the decibel numbers decibel numbers are March March simpler now let me come to testing gain coding by extra program testing can be a very effective way to show the presence of bugs but it is hopelessly hopelessly inadequate for showing their upsell it can never be a proof of correctness so fundamentally if you are concerned about correctness reliability or program what we are seeing is the program programmers should try not to introduce those errors to start with meaning you have to you have to spend enough time on the problem understanding specification design through it the design is correct and then finally take it into code and as far as maintenance is concerned we as we said earlier the more the complete complete the specification less the maintenance and in this context maybe I can tell our our experience uh even the computer science and engineering department website it was created uh 10 years back it is still running and we had the clear intertention of I mean less maintenance or design ruggedness and we know that we don't have people uh regularly for maintenance and you may be surprised that with the student into the project we took more than one year when you know that this website can be created in few days know that but the indication I mean what I wanted to stress is that 10 years back we created we are still using that same website design at that time computer science and engineering website ultimately to conclude we say that to have Reliable Software the product is not just the code it must contain the components like you must have a specification so that note that you can have the cost estimate or the time estimate of a software project only if you have a specification of complete specification otherwise you cannot do that or I'll say you cannot do it precisely so you have to have a specification and you have to have the program it may be I mean the design plus code in whatever programming language we here meant most of them I mean the stresses on the design and of course it it will have finally the code in whichever programming language you wanted to convert or translate it into and the final thing of course is the proof of correctness which is basically telling that the program satisfies the specification so so note that ultimately the product has to be these three components and normally we may just give the program that's not sufficient you must have a specification you must have a program you must also have a proof of correctness in our course we ask we ask the students to write even in English sentences or argue we say we say that effective use of English language is sufficient for the timing you can have the formal proof using predicate calculus or and Associated things or rather classical algorithm proof which we do in our process sort of but in this course we said effective arguments is to start with that is sufficient I mean I'll say effective use of human language English which is inherently ambiguous so I'll just mention some one of one or two of the references which I have used as well as talk is concerned we have been looking for a textbook experts uh this course is concerned and we found structure and interpretation of computer programs I should say that this was the origin where we started but we have gone much beyond that but the concepts of Brazil abstraction I mean that abstraction and modular design is there in that textbook so we still hold on to that and the principle of uh separational concerns I mean it is mentioned by dextra in the article on the role of scientific thoughts and we mentioned about the proof of termination and the concepts there it is there in the book might be I mean by Benjamin CPS types and programming languages I mean there are many other articles by diastra which we I have taken many codes and it is all available in University of Texas Austin uh in this site all the articles by dice rice archived by them uh that ends my talk thank you for listening the first question here is from Sharon I don't know how to pronounce uh he asked in the web and application field in the work sector what's the difference between a software engineer and a full stack developer uh I'm not sure how exactly to differentiate but from this talk what exactly I can say is that suppose we say software engineer my take is that if we consider engineering as a discipline like any other engineering discipline you go to shop and you buy any I'll say electronic equipment you get a guarantee card so ultimately I'll say that software whatever it may be whatever it may be application software included you should have a guarantee whatever name you call does not matter finally the product whatever be the product must have a guarantee that it satisfies the specification I don't know whether I mean uh I I should have a further question on to that maybe I'll take the next one uh so when you when you have a problem to face as simple as adding a new button to an application the separation of concern comes into play and does separation of concern goes hand in hand with testing no I I don't know whether I got it right so but I can tell very clearly in fact we would like to say that is as we if you adopt this methodology we clearly said the proof goes and in hand in hand and we don't have testing ideally we don't test because with the design itself we have already proved that it is correct okay so ideally I'll say there is no testing and remember testing cannot be accepted as a proof finally you cannot prove by testing that's just quote and let me come to the next one by Vivek finally the question is do you think the next generation of programmers takes program specifications seriously ultimately the point is that if you don't have a specification what are we doing I'll I'll stop at that point without specification what are we doing we should be very clear what we are doing and that is actually given by the specification note that so any project going ahead without the other the specification with the completeness uh unambiguous non-contradictory things definitely will land into trouble what will be the project that's the way in which I can possibly answer to that question Vivek and then Kumar is it true that future is without coding and running the predetermined workflows uh I'll say Kumar uh definitely there are efforts regarding uh a generating code from specification in compiler but that's my area we know that lexical analysis are generated from specifications uh uh and similarly uh syntax analyzer is generated from specifications you don't need to write code you have to give the specifications but uh but it requires effort as far as any new problem area to find an appropriate formal language to specify and if you can do that finally there is a possibility for Generation so right now you have areas where uh you have formal language to specify from the you can automatically generate like lexical analysis and synthetics and lexical analyzer and syntax analyzer and compilers now people don't write it it is generated from specifications is an AI private gold generator yeah ultimately code generator I mean you need specification formal specification rupee formal specification to have code generation automatically right otherwise we have to write okay a creates program with opengpt from symbol descriptions descriptions shall we make on doubtful I mean I'll say that okay the specification when I say we have put three conditions an ambiguous non-contradictory complete I'll say any mechanism through which you satisfy these conditions I can consider it as a specification so simple descriptions I'm not sure what exactly that is okay if these conditions are satisfied yes I'll take it as a specification then you can proceed from okay I think that's all the questions if I can find