Course Summary Fall 2005 CS 101 Aaron Bloomfield

Course Summary Fall 2005 CS 101 Aaron Bloomfield 1

Course Reflection 2

Course goals o Objectives: Students who complete the course will: n Understand fundamentals of programming such as variables, conditional and iterative execution, methods, etc. n Understand fundamentals of object-oriented programming in Java, including defining classes, invoking methods, using class libraries, etc. n Be aware of the important topics and principles of software development. n Have the ability to write a computer program to solve specified problems. n Be able to use the Java SDK environment to create, debug and run simple Java programs. 3

Unstated course goals o Everybody needs to have a “base” level of programming to continue on in the CS courses (or as required by other departments) n CS 101 and 201 provide that “base” level 4

What was new this semester o o o o Test code required n In hindsight, this should have been explained better More TA office hours n This was well received by everybody Faculty mini-talks n Had trouble scheduling this in a coherent way, so only one happened this semester. Should I do more? Labs n Many were improved upon, and a few were added Increased number of HWs by 2 Final few assignments were for a common big program n In hindsight, we see a better way to implement this next semester 5 Changing of the order the chapters were gone over

Changes on deck for next semester o o o o o Will keep (and improve upon) all the stuff from the last slide Study groups n The idea is a way for people to study and/or work together o This does NOT mean group assignments, however n There were not enough people to make this work this semester Probably will ditch Code. Lab - it didn’t work as well as I had hoped n It’s a good idea, but a real pain to manage properly I want to talk about debugging more n We are considering a site license for the debugging version of JCreator Better web site design (it’s in development now – thoughts? ) Will most likely lower the number of midterms to two (and require the final) Want to put more diagrams in the slides (make them more visual) Will have the TAs give review sessions before the tests Might have forums/newsgroups on the website 6

What didn’t work this semester o o o I botched a lecture back in September (in chapter 3) n With this fixed, I’ll have freed up one more lecture session n Plus one for the removed midterm A number of things worked, but need improvement (mentioned before): n Implementation of the game n Faculty mini-talks n Required test code The semester schedule (i. e. Thanksgiving break) made it difficult to properly teach arrays n There wasn’t a HW on 1 -D arrays as a result n This won’t be a problem in the spring, but will be next fall Had a bit of trouble keeping the lectures interesting towards the end of the semester Want to lower the amount of student frustration 7

What did work this semester o o o o This class learned much more than last semester’s class did n Even if you feel confused now, take my word for it n And as my goal is to teach (and not to be popular), this is a good thing Changing of the order the chapters were gone over Improved TA office hours Improvements to the labs Grading system worked very well this semester All the code on the website Many things that were “behind the scenes” n TA organization and utilization n Grading system n Me delegating the work better to the TAs 8

Did I push too hard this semester? o o o I pushed the class much harder this semester than last semester But did I push too hard? Consider: n I’ve gotten as many “things are going great” comments as I have “things are too hard” comments (anecdotal) n Homeworks took under 5 hours on average o The results from the survey questions for each HW n There were 8 HWs over about 16 weeks o That’s 2. 5 hours (on average) on homeworks per week Ultimately, I think that with a bit better organization, I can lower the amount of time spent on the HWs while still having people learn the same amount I’m interested in your feedback on this! n But not today in lecture…. 9

The Big OOP Picture 10

The classes for the game o o o o Creature (HW J 6) Weapon (HW J 6) Room (HW J 7) Map (HW J 8) Game (HW J 8) Parser (lab 9) Descriptions (lab 10) Map. Printer (lab 11) 11

How a big OOP program interacts o o Note how the classes interacted in the game A lot of objects were created and manipulated n A Room for each spot in the grid n Creatures and Weapons for some of the Rooms n A Map object n Etc. The way this game has objects interacting is how a big OOP program would work Encapsulation n The Room class didn’t need to know how the Creature class kept track of whether the monster was angry or not o It just called get. Angry() and set. Angry() o It could have been stored as a boolean or an int 12

Problem solving o o o To solve a problem in CS, you break it down into smaller and smaller pieces A big program is broken down into packages n Which we haven’t seen yet n Consider the game to be one package The packages are broken down into hierarchies n This uses inheritance n Our game didn’t use a hierarchy, as you did know of inheritance at that point The hierarchies are broken down into classes n The game had 8 classes Each class is broken down into methods and variables n Some (such as Map. Printer) only had 1; others (such as Map) had dozens Each method is broken down into parts, etc. 13

The completed game o o o This could easily be made by multiple people n Each person does a separate class n Not exactly equal, but it still lowers the workload Our (fully commented) code for the game was over 1, 300 lines However long yours was, it was a program greater than 1, 000 lines n Even if you had trouble getting parts working, and had to use our code n You still wrote part, and saw how it interacted with the rest of the system 14

Review of Chapter 1 15

Demotivator winners! n Methodology – 1 st place vote counted for 3 points – 2 nd place vote counted for 2 points – 3 rd place vote counted for 1 point n Will buy two demotivators and hang them in my office… n The results, with 137 of 173 precincts reporting… 16

Engineering software o Complexity of software grows as attempts are made to make it easier to use 17

Software engineering o Goal n Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable o o Makescorrectly Work Because Cost Design tosense software develop of the due and so long to and not that the fail lifetime maintain new greatfeatures costs many should involved and people not capabilities to will exceed have be involved expected can flexible be added components benefit that can be used in other software n Creation n Debugging n Maintenance n Enhancement Two-thirds of the cost is typically beyond creation 18

Principles of software engineering o Abstraction o Encapsulation o Modularity o Hierarchy Determine relevant Ranking orthe ordering of properties and features Separate Construct components a system from into objects whileand ignoring external and internal components packages nonessential aspectsdetails 19

Object-oriented design o o Purpose n Promote thinking about software in a way that models the way we think and interact with the physical word o Including specialization Object n Properties or attributes n Behaviors 20

Programming o o Problem solving through the use of a computer system Maxim n You cannot make a computer do something if you do not know how to do it yourself 21

Problem Solving Process o What is it? n Analysis n Design n Implementation n Testing 22

Problem Solving Process o What is it? n Analysis n Design n Implementation n Testing Determine the inputs, outputs, and other components of the problem Description should be sufficiently specific to allow you to solve the problem 23

Problem Solving Process o What is it? n Analysis n Design n Implementation n Testing Describe the components and associated processes for solving the problem Straightforward and flexible Method – process Object – component and associated methods 24

Problem Solving Process o What is it? n Analysis n Design n Implementation n Testing Develop solutions for the components and use those components to produce an overall solution Straightforward and flexible 25

Problem Solving Process o What is it? n Analysis n Design n Implementation n Testing Test the components individually and collectively 26

Problem Solving Process 27

Tips o Find out as much as you can o Reuse what has been done before o Expect future reuse o Break complex problems into subproblems 28

Tips o Find out as much as you can o Reuse what has been done before o Expect future reuse o Break complex problems into subproblems Consider Research can is require and generate questions Find out what knownsignificant about thetime problem Sketching apresenter solution andbecause then repeatedly its components The worthwhile the resultrefine is a better Talk effort to theis until the entire process is specified understanding Determine what attempts have succeeded and what attempts True of the problem makes it easier to solve have understanding failed 29

Tips o Find out as much as you can o Reuse what has been done before o Expect future reuse o Break complex problems into subproblems Your Be open timetoisindirect valuable use of existing materials Correctness is probably even more valuable Use existing infrastructure that is known to work 30

Tips o Find out as much as you can o Reuse what has been done before o Expect future reuse o Break complex problems into subproblems Make as few assumptions as necessary Maximizes the likelihood that your effort can be used in future situations 31

Tips o Find out as much as you can o Reuse what has been done before o Expect future reuse o Break complex problems into subproblems Divide-and-conquer Solve subproblems and combine into an overall solution 32

Have a great holiday break! 33