Class Note for EECS 448 with Professor Niehaus at KU 5
Class Note for EECS 448 with Professor Niehaus at KU 5
Popular in Course
Popular in Department
This 17 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 19 views.
Reviews for Class Note for EECS 448 with Professor Niehaus at KU 5
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 02/06/15
Overview Tools of the Trade SWEs work on various aspects of the Unified process for many many many hours a week Many parts of the process are supported by commonly used methods and tools Many different levels of presentation and integration exist for various tool sets Individual tools used separately Chapter 5 39 Progralmmer s Workbench I Single unified GUI for every operation EECS 448 Emacs Eclipse Visual Studio Which tools a SWE uses is important But how and why they use them is most important PolicyMechanism distinction is important EECS 448 1 Dr Douglas Niehaus 2009 EECS 448 2 Dr Douglas Niehaus 2009 Dr Douglas Niehaus Overview Stepwise Refinement Policy Stepwise refinement is an approach to problem What you are trying to accompiish in the SWE solving which is used to control complexity in a wide Unified Process workflow variety of human activities Editing compiling documentation Software Engineering is a prominent example teStlngys39EUdylng COde deSIinng GU39S General strategy is to postpone decision making Mechanism until as late as possiblequot How you accomplish your purpose Make design and implementation decisions at Supported by some tool or other each stage that need to be made but do not make those that can be postponed GUI editor Syntax aware editing Make command prnit etc As late as possible but no later Methods of doing work are included in the term even 39 SWE Shou39d conStantly akv What are the m05t when not explicitly supported by a tool important and productive issues I can be working on nowquot EECS 448 3 Dr Douglas Niehaus 2009 EECS 448 4 Dr Douglas Niehaus 2009 Stepwise Refinement Stepwise Refinement Humans can only concentrate on a finite number of Especially important in the objectoriented paradigm issues at any giVen time Underlying lifecycle is iterative and incremental Classically cited as 7 but there is a lotof individual Example Var39f 39O 39l th39s Updating a master file Stepwrse refinement as an organrzrng strategy permits one to concentrate on the most productive TransaCti0n33 insert mOdifya delete components at each stage Three representations Deciding tOO early Wastes effort bYmaking Successive refinement is usually easier that decrsron harder or making it more likely it Will have producing the final design in one step to be Undone later Many quick iterations is often faster than a few Deciding too late can also waste effort by causing slow iterations other dec39s390n8t0 have t0be undone Maximize productivity by concentrating on most Applies to analysrs desrgn Implementation and productive work at each moment testing workflows in various ways Stepwise Refinement Stepwise Refinement Figure 52 First representation of the problem Figure 53 First design refinement New master on le update if master file update Exception master gt report file V I l Trans wm input process output me Summary and endofjob message EECS 443 7 Dr Douglas Niehaus 2009 EECS 443 3 Dr Douglas Niehaus 2009 Stepwise Refinement Figure 56 Second Design Refinement update master file I I r I r A I i ompare i transaction record key mpm M pm lt gt write k new master file lransaclron record est transaction MODIFY perrwm modification 53960 EECS 448 9 perform deletion perform memoquot error error Ur Douglas Niehaus 2009 CostBenefit Analysis Costbenefit analysis is a method of choosing among several alternatives Feasible is the benefit worth the cost Preferable alternative with the best return on an investment of effort Examples Determining whether a given industrial process should be automated Cost of automation hardware and software measured against money saved as a result Tangible benefits are easy to measure but intangible are harder to quantify Many assumptions and predicitions EECS 448 11 Dr Douglas Niehaus 2009 Stepwise Refinement Figure 57 Third Design Refinement WWW Maximum 122 productivity by working on most 1 important open issue K AquotIj II In mad Emnsudluri me umscr WEI at each moment 151 mam m lt rmnsnmur 2 rrmstellrlr lt5 rransacrrun mpg record rypz readnid masterlrle ll vSEllIMODH Y DELETE letuld INSERT MODIFY DEKETE 951ch Write new i wtllEnEw perform ptricrrrrr my routine maita IIe X mazrrr Illa Nmr mar record 7 emrd m urine routine l 39 rud I cad Immacuon Immunequot lrle le i rquot F 11 41 EECS 448 w mug mamas svva CostBenefit Analysis Any costbenefit analysis should highlight Assumptions made Reasoning used to produce cost and benefit estimates Same principle applies to a SWE asking what should I work on today Time is the most common cost but Time is Money Will working on one component today provide a greater benefit than working on another Example Computerizing a company s billing system Advantages Bills mailed monthly vs every 2 Improved cash flow 80 Billing clerks replaced by 11 DataCapture clerks implies large salarly saving EECS 448 12 Dr Douglas Niehaus 2009 CostBenefit Analysis Disadvantages of automated billing Cost of data processing department Cost of hardware and software Cost of PostDelivery Maintenance Costbenefit analysis applies at all levels of complexity High decide on whether a large project is worthwhile Low Decide on what to work on this afternoon EECS 44B 13 Dr Douglas Niehaus 2009 Software Metrics Lines of code still remains among the most common Measures progress in creating a product Serves as a components of other measures Faults per KLOC Measurements during short periods are subject to a wide variety of influences Really hard problem sickness etc Over a longerterm monthly perquarter yearly they are often more useful Programmer produces 3 KLOC per month Mean time between failures Another common metric for software and hardware EECS 44B 15 Dr Douglas Niehaus 2009 Software Metrics Metrics refer to methods of measuring some aspect of some topic of interest Quantification is good in most cases although not if it gives a false sense of precision Qualitative reasoning often required though less easy to formulate A is hard B is very hard so A is easier than B but by how much Some level of classification and uantification for topics of interest is desirable as t is leads to Monitoring progress Schedule milestones Lines of code fault rate etc EECS 44B 14 Dr Douglas Niehaus 2009 Software Metrics Some metrics can be applied throughout SW process Effort on each workflow measured in person months to track biggest resource for most projects Salary Staff turnover is another important metric Longerterm statistics can enable management to detect problems Eg high turnover in PDM groups Cost in general is among the most important but is often derived from others in several steps Salary turnover purchases hardware office space heat light etc EECS 44B 16 Dr Douglas Niehaus 2009 Software Metrics Software Metrics Product Metrics vs Process Metrics Product metrics measure some aspect of product itself obviously KLOC Reliability Performance Process metrics measure how product is produced Efficiency of fault detection Ratio of faults detected during development vs total number detected over product lifetime Metrics may also be specific to a workflow LOC obviously irrelevant before implementation EECS 44B 17 Dr Douglas Niehaus 2009 CASE Number of faults relevant to several workflows Requirements analysis design implementation testing documentation etc Cost is also involved in gathering data required to compute metrics of interest Costbenefit applies to deciding to use metrics Gathering cost computation cost tool cost What do software organizations commonly measure LOC lines of code Cost in dollars Duration in weeks months years Effort in personmonths Quality number of faults faultrate EECS 448 18 Dr Douglas Niehaus 2009 CASE ComputerAided Software Engineering CASE refers to the use of tools to assist SWE to do various aspects of their jobs more efficiently or effectively Commonly used to help with complexity but can also be used to speed some common activities Taxonomy of CASE Simplest form is the tool UpperCase front end tools for earlier work flows requirements analysis design LowerCase back end tools implementation and postdelivery maintenance EECS 44B 19 Dr Douglas Niehaus 2009 Classes of CASE tools Data Dictionary computerized list of all defined data types variable names etc Consistency Checker checkin that every item in a specification document is ref ected in the design and viceversa Report Generator generate the code needed for producing a report Screen Generator generate the code required for a data capture scree GUI design and codegenerator tool Implementation support tools Edirotrs compilers make GDB PyUnit etc EECS 44B 20 Dr Douglas Niehaus 2009 CASE CASE workbench is a collection of tools that together support a set of SWE activities Programmer s Workbench in ATampT UNIX Editing compiling linking testing debugging Source code control and documentation CASE environment supports the complete software process or a significant portion of it Remember PolicyMechanism What you are trying to accomplish vs how a tool helps you accomplish it EECS 448 21 Dr Douglas Niehaus 2009 Scope of CASE CASE Examples Online documentation UNIX manpages or Doxygen output Email filters storing projectrelated messages automatic messages generated by faults or source code control data base commits Editors Syntax aware syntax colorization Object hierarchy aware TAGS crossreference listing automatic format Integration of editing compiling debugging Scope of CASE can vary single module many modules many develoipers EECS 448 23 Dr Douglas Niehaus 2009 CASE Various scopes of CASE a a tool b a workbench c an environment Requirements Requirements Requirements workflow workflow workflow Analysis Analysis Analysis workflow workflow workflow Design Design Design workflow workflow workflow Implementation workflow Implementation workflow Implementation workflow Postdelivery maintenance a b C EECS 448 22 Postdelivery maintenance Postdelivery maintenance Dr Douglas Niehaus 2009 Software Versions Real products are built at a scale that requires version control Scope in size Scope in Time Source code control tools vary in their models All support versions of individual files Some support binary files better than others Some support versions of sets of files better than others Should be used from first day in managing a product EECS 448 24 Dr Douglas Niehaus 2009 Software Versions Revision New version of a product produced by changing one or more of its components Version control system stores multiple versions for many reasons Multiple product versions supported in filed Multiple versions at various stages of implementation Current development unit testing integration testing etc Version control is a form of insurance Mistakes in the working directory can often be fixed by reverting to a stored version EECS 44B 25 Dr Douglas Niehaus 2009 EECS 44B Configuration Control A configuration control system can automatically manage multiple product variations Closely related to version control May or may not use version control Can also rely solely on product configuration options from a single set of source files Compilation flags Linking flags makefile Flags can all control what software is produced and Software Versions Versions of a file track changes to each source file History of text based files are much easier to track read and understand than binary files Drawback of MSWord or OOWriter vs Latex Histories are more often important for source code files than documents Versions of a product are build from a given set of files each at a specific version Version control data bases must be able to track version of a product Tags ID numbers explicit lists 26 Configuration Control Control of compilation Figure 512 is a major form of configuration control but not the only one Run time routines Executable load image Dr Douglas Niehaus 2009 how it is bundled Compiled Code for a given module can take several forms le Compiled file 2 Compiled file 3 Compiled file n Source code object code executable files configuration files etc Which libraries are used can make a lot of difference EECS 44B 27 Dr Douglas Niehaus 2009 EECS 448 Source Source SourceN file 1 file 2 file 3 28 Source file n Dr Douglas Niehaus 2009 Configuration Control Version and Configuration Control Tools Configuration control at development time is Many versions of source code control tools important in SCCS RC8 CVS Subversion Tracking specific versions for release Classic centralized methods Notifying developers when both edit a given file Git Mercuria hg Bazaar bzr Configuration control also important in PDM Distributed methods Preserves information required to build a product Commercial in complete and executable form makefiles pVCS Sourcesafe Microsoft 39 I39mpoltant sou ce ff 39nformat39on for someone Configuration determined by set of files used to build I 9am3909 a pro C I a product and the set of burld options chosen DIstIngwshes between deployed versrons that may Bridge from version control to build tools each require PDM Notification of PDM fault correction overlap in source modifications EECS 44B 29 Dr Douglas Niehaus 2009 EECS 44B 30 Dr Douglas Niehaus 2009 Build Tools Build Tools Build tools assist in constructing a given version of a Complex products can be built from hundreds of files product in tens of directories UNIXLinux make command classic example Linux Kernel Can fairly easily be integrated with version control GNU Compiler tools gcc g gas d etc Use of standard targets Data Bases MySQL Oracle etc Automatic support for product compilation is Makefiles are an example of a production language important for several reasons target inputs Preserve complex compilation commands construction steps 39 AUtomatiC eXeCUtion Dependency analysis constructs a dependency Compile and link flags provide many configuration graph among makefile targets Opt39ons Target of upstream step is an input of a Minimal recompilation work can save time downstream step EECS 44B 31 Dr Douglas Niehaus 2009 EECS 44B 32 Dr Douglas Niehaus 2009 Build Tools Productivity Gains with CASE Source and header files are inputs to produce object Researchers have investigated productivity gains files which in turn are inputs to produce executables with CASE tool use Changing a single header may imply recompiling a Average gain of 9 to 12 large number Of mes Cost per user of CASE introduction 125K Changing a single source file may only require recompilation of that file and relinking product 39 Trammg and ramp Up penOd m add39tlon to COSt of the tools themselves 39 makefi39e enCOdes a important relations among Significant time may be required to learn how to files relevant to producmg a product use a tooi productively 39 MUSt be debugged I Annual cost of nonfree tools must be considered Many common practices related to reliable and Open source CASE environment Wideiy iooiouiar prOdUCtiVe make le use for this among other reasons CASE benefits include shorter development time and improved software quality EECS 44B 33 Dr Douglas Niehaus 2009 EECS 44B 34 Dr Douglas Niehaus 2009 Productivity Gains with CASE Conclusions Newer results on CASE benefits CASE Tools are extremely39important and can 100 development projects at 15 Fortune 500 Increase IOFOdUCthlty Significa tly bUt mUSt be companies understood and used appropriately Teams using CASE provided with training CASE environments should not be used by increased user satisfaction organizations at CMM levels 1 or 2 increased scheduie satisfaction A fool with a tool is still a fool but often more dangerousquot Teams without training Delivered late Less user satisfaction CASE tool use in conjunction with structured methodology Increased performance by 50 Compare how scared you should be of 1 an idiot with a saw and 2 an idiot with a chainsaw Learning some set of tools we is important in learning the Policy goals of a given class of tools This deep understanding can often be transferred to mechanisms of other tools EECS 44B 35 Dr Douglas Niehaus 2009 EECS 44B 36 Dr Douglas Niehaus 2009 Conclusions Conclusions Learning commandline free open source tools has Open source CASE tool list seVeral adVantageS Editors vim or Emacs Widely used because they are effective and free Compilers GNU tools gcc gy gas dy etc Require somewhat more userthought Debuggers GDB DDD involvement and effort Source code control cvs svn it bzr Better for achieving a deep understanding of g the policy level issues Configuration control make CASE IDEs are then easier to understand and easier 39 TeSt39ng JUn39t Pyun39t to move among Documentation Doxygen What am I trying to do and how is this tool trying 39 IDE EClipse etc to help me do itquot These are available on a wide range of platforms including on Windows under cygwin environment EECS 44B 37 Dr Douglas Niehaus 2009 EECS 44B 38 Dr Douglas Niehaus 2009 Classic CLl CASE Tools IDE CASE Tools Editors Eclipse I I Vi Vim emacs xemacs OrIgInaIIy targeted at Java but wrth plugins for other languages C C Python others 39 comp39lers Integrates gcc cvs gdb makeANT using plugins GNU Compiler Suite gcc g objectiveC etc Anjunta Binutils gas dy objdump etC Independent project for CC IDE Debu er Code Warrior 99 I Commercial Linux and Windows GDB DDD Insrght wxstudio Source Code Control 39 Python and C I I CV8 subversion Emacs Is ar uabl a CLI IDE In which many features of more mo ern UI IDEs were first created or at 39 git hg bzr least popularized before GUI widget sets became Configuration control ubiquitous make Many many many of them EECS 44B 39 Dr Douglas Niehaus 2009 EECS 44B 40 Dr Douglas Niehaus 2009 Editors Editors Editing text files is the common requirement Most modern editors support most of this Distinguishing characteristics are degree of Emacs Vim eto automated support for editing39different kinds of files Details of reaming curve for customization can be PlugIn or module based architectures are common important for creating additional capabilities Some kind of scripting support for adding abilities Language support Intelligent context sensitive indenting Syntax highlighting Emacs really is complicated in this respect Emacslisp Python environment available Still useful without massive customization Learnin to be really good with editor of your choice BraCket matChmg is moregijmportant than using a particular one 39 comment folmattm Vi is a good backup to know as it is on every Linux Keywordvariable name completion system by default Dictionary integration EECS 44B 41 Dr Douglas Niehaus 2009 EECS 44B 42 Dr Douglas Niehaus 2009 Editors Compilers Establish your own methods and learn to use them GNU compiler suite is ubiquitous and generally good well with consistent refinement over time You can probaby get it for any patform you are You spend a truly huge amount of time editing so using making that phase more efficient is a big benefit Many other oompners are better for specific Chan ing your editor may be required to conform to situations particularly parallelization for Grids speci IC organization requirements poruand Compuer Group for exampe 39 AUtomatiC COding Standards compliance perhaps However CLI interface of this set is a classic model Avoid religious wars while remaining open to new fOHOWed by mOSt CLI compilers and Wrapped by information mOSt GUIS I spent 3 years in graduate school telling people 39 QCCQ 39 Wrapper WOUId nOt learn Emacs When they suggeSted it cpp preprocessor cc1 compiler gas assembler The last 3 years were much more productive after d unker objdump exeoutabe anayzer I started using emacs nm symbol table EECS 44B 43 Dr Douglas Niehaus 2009 EECS 44B 44 Dr Douglas Niehaus 2009 Compilers Compilers gcc v gcc dir 39 Narrative Of What is happening in all phases Add dir to list of places searched when resolving a Very useful to learn interesting details inCiUde statement gcc S Added in order specified but before standard Output assembler code direCtory St 900 C 39 gCC L Compile only to object file Add dir to list of places searched when resolving a gcc 0 execname name reference to an object library ibnamea Output linked exec file into file named execname 39 A apply to 9 rather than aOUt Profiling and other options exist as well 39 900 399 Read gccg manual page periodically Include debugger information several variations EECS 44B 45 Dr Douglas Niehaus 2009 EECS 44B 46 Dr Douglas Niehaus 2009 Debuggers Debuggers GDB is the classic CLI source level debugger Effective use of a debugger is second only to Other environments have equivalents effective use of an editor in increasing your CLI is less useful because you have to keep a mental IOFOdUCtiVity I picture of where you are in the source files EXcellent for learning how code works as well as Some IDE integration required debugging I I I EmacsI DDDI lnsightI EclipseI etc Often fairly enVIronment speCIfIc Breakpoints print variables structures etc 39 Remote debugging 0f embedded systems Hardware breakpoint or watchpoint registers can be Sophisticated use has no bound but basic use is the important for increasing performance in certain cases most Important and perfectly fine forever Scripting can be very useful Basic scripting in GDB proper Archer project included in Fedora 11 integrates Python fuy by all indications EECS 44B 47 Dr Douglas Niehaus 2009 EECS 44B 48 Dr Douglas Niehaus 2009 Source Code Control Source Code Control CVSSubversion is the classic example Frequent commits are a form of insurance 39 VerSion traCking 0f eaCh fiie Commit when you have typed more than you could Comments indicating changes in each version are recreate from memory important You should not commit only meaningful versions 39 Printing hiStory 0i eaCh iiie Certainly commit milestones representing new Tagging or other representation of a set of files capabilities or paSSing SpeCifiC teStS representing a version of the product to which you Classic scenario W39Sh to return Horrible bug you cannot figure out 39 common work pattern Restore previous working version and make the 39 Update local workin directory tree before starting changes you are sure shoud work but are not new work periodica y or when notified They work 39 Make Changes for your purpose Because you made some other mistake you do Commit your changes not remember EECS 44B 49 Dr Douglas Niehaus 2009 EECS 44B 50 Dr Douglas Niehaus 2009 Source Code Control Source Code Control Branches Conflicting edits Permit your line of development to be kept Code control requires users to take a cop out for separate from others editing which is not CVSSubversion mo el Avoid compiling or functional problems of updating Returns error to second user to take a given file the trunk development out for editing on a given branch Merging Opportunity to talk to concurrent developer Bringing changes from a branch into trunk Opportunity to create a branch In general harder the longer branch development 39 Conflicting merges has continued Constrains concurrent development less May conflict with changes made to code since root Can lead to unpleasant surprises of branch or on another branch Classic tradeoff Constrain concurrent edits or conflicting merges EECS 44B 51 Dr Douglas Niehaus 2009 EECS 44B 52 Dr Douglas Niehaus 2009 Duplicated work Conflicting designs Source Code Control Configuration Control Many sophisticated uses of source code control are Make tool is the classic example possible but basic use it often sufficient Describes inputs production steps and target Administration of a repository a bit harder produced with each rule Patterns of use are at least as important as specific Defined variables permit considerable customization commands and flexible configuration at execution time Need to be compatible among fellow developers Compilation flags installation directories etc Binary files can be harder if conflicts arise Hierarchical organization is relatively simple With a text file at least tools put conflicts sideby ibxa side lineby ne cd ibxdir make 39 DiStribUted and intermittw y conneCted tOOIS Tutorials and other documentation widely available becoming more popular gIt bzr Compile test bUIId documentation Install prepare 39 l eam39ng pr39nc39p39es and apply39ng them mOSt release images can all be done with separate targets Important EECS 44B 53 Dr Douglas Niehaus 2009 EECS 44B 54 Dr Douglas Niehaus 2009 Emacs vs Vim Emacs Classic debate Start used vi for 10 years before switching to Emacs bashgt emacs Some basic knowledge if Vi is wise as it is always bashgt emacs nw 82 a LinUXUnix maChine Whereas Emacs may Qt No windows version good for ssh connections Cx Cc controlx controlc exit Cg oops get me out of this Cx u undo any number of times Major difference modal vs nonmodal editing Vi Esc key used to exit editing mode Append used to enter editing mode Open file cXf Emacs generally far more powerful and fleXIble S C C earlier in history but many similarfeatures are 39 aw X 395 available for vim vi improved NaVIgate arrows mouse Cletters I d have to look A fairly small set of Emacs commands are a good them up foundation EECS 44B 55 Dr Douglas Niehaus 2009 EECS 44B 56 Dr Douglas Niehaus 2009 Emacs Emacs Frames Buffers Multiple buffer views in single window Open a file CXf CX 3 split vertially takes you to mode line and you complete file CX 2 split horizontally name I CX1 make current frame only one CX b swrtch to another named buffer CX 0 delete current frame CX Cb create another frame listing all open 39 H buffers CX o swrtch to other frame This 0 cles thou h a set of more than 2 39 Edmng y g Delete and backspace remove characters to right EECS 44B 57 Dr Douglas Niehaus 2009 of curs or Insertion just type CX space set mark EECS 44B 58 Dr Douglas Niehaus 2009 Emacs Emacs Cw delete from mark to cursor Compilation Cy yank most recently deleted buffer into cursor MX compne position My replace yanked text with previous buffer Rinse and repeat M is meta key Alt on most keyboards Named buffers CX r s a save selected rectangle in register a CX r l a insert contents of at point Directory browsing CX f open directory Put cursor on member and open it with f EECS 44B 59 Dr Douglas Niehaus 2009 Lets you edit compile command Call to make by default Captures compilation output in buffer Good for review IC X goes to location of neXt compiler error Debugging Mx gd b Splits current frame into GDB and source view CX space sets breakpoint at current line nor EECS 448 s neXt and step as at gdb command line 60 Dr Douglas Niehaus 2009 Emacs Emacs Automatic code arrangement Learning how to do these kinds of things in any Tab automatically indents editor is a good idea CM auto indent a selected block Emacs can do them all and lots more depending on Mf and Mb at bracket moves to complementary what you want and how much you work to learn how braCket Emacs is easy to learn at the level I know it Mq within comment automatically paragraphizes Quite good it as with text editing M create blank comment Good customization target Tags Crossreferences source code Permits navigation to definition of variables structures procedures across source file boundanes EECS 44B 61 Dr Douglas Niehaus 2009 EECS 44B 62 Dr Douglas Niehaus 2009 Learning to be that good in your favorite editor is beneficial Conclusion Foo Knowing the policy level capabilities of all the basic foo Programmer s workbench is a good idea for knowing what you want to learn in any environment Learning mechanisms of these classic CLI commands is a good way to learn the right level of detail Available in a wide range of environments Policy applicable to all environments EECS 44B 63 Dr Douglas Niehaus 2009 EECS 44B 64 Dr Douglas Niehaus 2009 FOO foo EECS 448 65 Dr Douglas Niehaus 2009