[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 14q.html Wed Jan 11 07:25:52 PST 2012


    Questions and Answers on Design into Code

      What is an IDE

      An Integrated Development Environment. Example Eclipse. For more look under the Menu in KDE, under Development.

      Chapter 20 pages 369 -- BEware of bugs in the above code

      "BEWARE OF BUGS IN THE ABOVE CODE." That is part of the quote from the beginning of chapter 20. Is it true that the first computer bug was an actual bug (I heard a moth) flying into the circuitry of an ancient mainframe.

      Yes, when Admiral Grace Hopper was a young programmer she did stick a fried moth into the console log as evidence of a "bug in the machine".

      By the way -- the word "debugging" was already in use at the time!

      Side track

        Donald Knuth (the source of the quote) is one of the great computer scientists. He is famous for the meticulous care he takes to prove and analyze algorithms. He also developed a major (and popular) tool in a very iterative way -- he paid people every time they found a new bug. He wrote a paper called "The First 700 Hundred Errors in ΤΕΧ" about this experience. I think that all CSci students owe it to themselves to learn about him... [ story.php?storyId=4532247 ] (news story with link to a 9 minute audio story).

      Chapter 20 pages 371 -- Mapping designs to code

      Do we have to write source code for all the classes showed in the class diagrams at the same time?

      For this course -- no. Unless you want to.

      In practice, you can't test until you have code for every class that you use. However, the classes can be full of stubs -- functions that are incomplete and return fake results.

      Normally you grow the code piece by piece -- class by class. You start work on a class by coding some unit tests.

      Chapter 20 pages 373 -- What is a DCD

    1. DCD::acronym="Design Class Diagram". It is a blueprint for some code.

      It is a diagram that shows the classes that you have designed, that will be put in the code. Each class is coded as a class, each attribute as a data member or field. Each operation becomes a member function or method. The associations become pointers and objects.

      A DCD differs from a Domain Model because <exercise>.

      Chapter 19 pages 366-368 -- Differences in Parameter, Attribute, Local, and Global Visibility

      OK. A method can only work if it has some data. Where does it get that data? There are four places where the data might be found: the parameters of the method, attributes of the methods'cs class, the varaibles declared inside the method, or in some global (or static) place in the system.

      Look in these places and you may find the data.... but if not you have to decide where to put that data so that the method can get at it.

      And sometimes you end up changing the design to make sure that the data is available via one or more new function calls.

      Chapter 19 pages 363-368 -- Visibility vs inheritance

      Is visibility in design be equivalent to inheritance in OO programming?

      No, not equivalent. But inheritance will make "protected" members visible to the classes that inherit them. In the context of this chapter.... inherited "protected" variables have attribute visibility. The private ones are not visible.

      Chapter 19 pages 363-398 -- Visibility and design patterns

      Does visibility change between different design patterns?

      Yes and no. Yes -- A different pattern leads to a different set of interactions and so you end up with the data being placed in different classes, and passed around in different ways. No -- the reasoning about what data is being transferred and where it comes from stays the same.

      Explain Global Visibility

      This is something we told you to not do in CS201 and CS202.

      Global visibility occurs when there is a single variable/object that can be used by any part of the software. It is easy to do this in C++ and difficult in Java.

      It is the most convenient and most easily abused visibility.

      Because any method in any class can access and change a global object, it is easy for bugs to appear that are unexpected. It is like having pockets that every body has access to -- no personal space.

      Chapter 14 pages 363-398 -- Visibility of global data assigned to local varaibles

      In web applications, I have seen programmers declare global variables(such as database info) in configuration files only to reassign them to local variables in a class(in this example, a database class). Is this good/common practice? What is the purpose of this?

      It may be common. I'd like to see examples to see if it is good. It smells of entangling the User Interface with a Technical Service. But the configuration file may actually act as a way of separating the design decisions.

      In some common rapid development environments you describe the web pages in an extended mark up language that lets you insert data from a database into the page directly. This gets the program working fast, I wonder how maintainable it will be. And I wonder if it can handle some of the more complicated computations that appear in some situations.

      Chapter 18 pages 363-398 -- Design Into Code

      Instead of visibility, could a user write pseudo-code and explain basically the same thing there?

      Yes. Whether you write pseudocode or draw class diagrams you still have to sort out where the data comes from and where it can be accessed.

      But reasoning is the same whatever expression the final form takes.

      How does visibility affect global variables?

      Not much! Global variables are just visible to the whole program. Coupled to everything! Anything you do, anywhere in the code, can mung a global variable. This seems good when you first begin programming.... but after a number (depending on the person) of bad experiences people tend to get rid of them.

      For example in my PhD graphics program I had three global variables: X,Y,SCALE that were available for drawing pictures:

       		X:=X+1; DRAW; Y:=Y+1; DRAW; X:=X-1; DRAW; Y:=Y-1; DRAW;
      These days we send commands to a graphic Canvas....
      You can see how seductive the global variable form was.... But [ test.Henrici.html ]

      Chapter 20 pages 370 -- Cycle of annoyance.

      As a novice programmer, I can easily see becoming discouraged by having to change documentation every time I think of a new method that should be added to a class, or a new class that should be added to the system. One of the important aspects of diagramming/planning is to give you a fuller understanding of what you will be working on; but constantly updating the documentation seems to me to be a distraction. Do you know how frequently technical writers with programming experience are employed for this exact purpose? Or is some poor sod of a programmer usually tasked with doing it?

      I completely agree that it is annoying to go back to adjust previous analysis and design artifacts. Indeed, in practice -- but not in this class -- I think we should only go back when we can see a value to it. I believe that well written code can can capture a lot of the meta-data that is discovered in diagrams.

      I don't think technical writers are or should be used for this purpose. There job is to prepare information for users, managers, salespeople, ...

      I remember a poor student, many years ago, in England spending the entire summer drawing a flow chart of a FORTRAN program. He was paid but what a waste.

      I remember flowcharting the machine code of a compiler I was modifying as part of my Ph.D. work..... until a faculty member asked why I didn't call the company up and ask them for their flowcharts. I hadn't thought of doing this! So I did.... and they said that they hadn't drawn diagram but had written it in Algol 60, would I like a copy. I said yes.... and there was all the information I needed.

      Any thoughts?

      Chapter 20 pages 374 : Exceptions

      How would exceptions or error handling be involved with the transition from UML to Code?

      There are notations in parts of the UML for showing exceptions. I don't want to burden you with these in this course. The official ones are used in activity diagrams (none of the diagrams we've met so far) and involve lightening strokes and little triangular "Delta" symbols. Follow Craig's notation in class diagrams:

       		{exception SmokingGnu}

      At the user level, alternate scenarios can probably be coded best using exceptions.

      The problem is that Java forces you to handle exceptions. My advice in this case is: don't clutter the UML design with exceptions but code them carefully. We will talk about some exception handling patterns later... meanwhile check [ patterns.html#Exception Principles ] for 4 useful hints.

      Should errors be handled by the object that detects them or by another

      object If you can handle them locally -- and hide there occurrence from the rest of the system this is good. But normally you need to at least record the errors in a log so that an administrator can spot trends.

      How are exceptions and errors handled handled when you have already

      planned for them It depends on your plan. All the book is suggesting is thinking about and possibly programming a simple central error handling subsystem early in the project.

      Chapter 20 pages 375-376 -- Order of implementation

      While in the test phase, are tests based on the logic of the DCD? Or, should tests be performed at random?

      Review Exercise: name the four phases of the UP.

      First -- there is no "test phase". Testing is done in every UP phase, and in every iteration.

      We have several types of tests.

      Unit tests make sure that a single class's reactions to various calls/messages are correct. They are based on the DCD plus other known properties of the objects. Started at the start of each iteration after Inception.

      Integration tests can be based on the interaction diagrams -- does this set of objects play together nicely? Probably in the middle of iterations.

      Other tests are based on scenarios in the use cases. Towards the end (but with small programs I do this first).

      Then we have client based "acceptance tests". Probably done at the end of iterations.

      Random testing has been used, successfully, by NASA to estimate the mean time to failure of software. They used operational scenarios weighted by the expected frequency of events in the real world.

      Chapter 20 pages 376 -- Test-Driven or Test-First Development

      About how successful are Test-Driven/Test-First Development projects?


      Chapter 20 pages 376 -- Test_Development TDD vs TFD

      What is the difference between Test Driven Development (TDD) and Test First Development (TFD)?

      Not much!

      Chapter 21 pages 376-398 -- Test-Driven Development -- TTD

      Isn't unit testing apart of test-driven development? It would be hard to test an entire program at first. You would need to break up the testing into sections.

      Unit testing is an important part of TDD.

      The classic form is: write a test for one new feature, make the program work by adding the feature, write a test for a new feature, fix the program,..... and so on. And then refactor the code. The tests accumulate as you complete the system.

      Chapter 20 pages 376 -- TDD order

      Is there any particular order when implementing the TDD method? In figure 20.7 we are given an order that seems a bit all over the place, is there logic to it? Or is it just how one feels on what they want to do.

      One of the nicest things about TDD is the freedom you get to adjust to the things you discover as you develop the code.

      However if you look, carefully at Fig 20.7 the order is determined by the arrows -- but backwards. The arrows indicate a strong dependency. For example "Sale" knows about a "Payment". And so we must get "Payment" up and running before we can start on "Sale".

      The jumping around is more apparent than real. You can probably do a PERT on it!

      Chapter 20 pages 380-400 -- What is TDD for

      So is TDD just a test or more than that?

      Kent Beck wrote an article Test First Development arguing it was a whole lot more than a test:


      1. Kent Beck
      2. Aim, Fire
      3. IEEE Software Magazine V18n5(Sep/Oct 2001)pp87-89 [ 52.951502 ]
      5. "Never write a line of functional code without a broken test case".
      6. Ward Cunningham: "Test-first coding is not a testing technique".
      7. Writing tests helps you understand the problem: analysis.
      8. Writing tests described the logic of the design.
      9. Hard to write GUI tests.
      10. Claims that creatively lazy test-first coding tends to be more cohesive and less coupled -- because the interfaces tend to be minimized to saving typing: "intense feedback substitutes for the ability to guess right"
      11. Test cases expose misunderstandings in pair programming.
      12. Test cases document the all important answer to "What was this idiot thinking when he wrote this?".

      Chapter 21 pages 386 -- Test Driven Development TDD

      Is TDD really feasible on a very large scale development environment?

      The British Civil Service included specifying tests as the last stage of design prior. But this was Big Design Up Front -- -- --(BDUF)
      So we specified pages and pages of tests -- covering every piece of code once and every decision -- both ways... A very different process but demonstrating that designing the tests first is possible. Indeed you will find it as part of the departments own IEEE based process.

    2. Chapter 21.1 pages 386 -- TDD The book didn't cover any disadvantages of using TDD, could you go over some that you mentioned in class? (if you did)

      I've yet to discover any disadvantages of TDD. But I don't think I've got any hard data.

      Chapter 21 pages 381 : TDD

      Should we be writing test code during, before, or after interaction and class diagrams?

      You can do the unit tests for any class when you know the attributes and operations. So, I figure that you can start unit tests while you are still working on the class diagrams. Possibly even earlier!

      Chapter 21 pages 387 -- Writing test code

      I haven't written "test code" for a program. Is this written code additional to the program code or is it part of the program code? Which add on testers work best in your opinion?

      Test code is additional code.

      I'm cheap so I tend to write the test code as the 'main' function, rather than invest in a tool. In C++ I use 'assert'.

      Notice -- user interface code is tested differently to the other layers. Test code exercises classes on your behalf. UI code has to be tested by Users.

      Chapter 21 pages 386-387 -- Test-Driven Development

      Who conducts this test-driven test? Is it an independent company that reports back to all stake holders or this refer to local / lab bench testing.

      For tests to drive development they must be done quickly and on site -- I like the term "lab bench testing" -- it has the right image to it.

      You can have two types of tests that can be used to drive coding: internal "unit" tests developed by the programmers and external "whitebox" tests developed by clients. Both are good for driving the development of code. For tests to drive the coding you need to be able to complete the tests quickly -- seconds rather than minutes. In XP the programmers start testing the code at the start of the week, and the client tests it at the end of the week's work.

      In some projects testing is done by a separate team or even a specialized "Quality Assurance" company. This does not provide the kind of rapid feedback needed to help the coder. The aim was to protect the stakeholders. This is an older procedure -- there used to be several local companies doing this -- I was involved in providing training to them in the late eighties. I associate it with government projects.

      Chapter 21 pages 385-389 -- eXtreme Programming

      When should one use XP and is it a good development process to use?

      We know that it works very well when you can get the whole team plus a user representative into a single room. Projects that need more people, or where you can't get a good user working in the team are a lot more iffy. Similarly if you can't afford to dedicate a single space to the client+programmer team.

      Chapter 21 pages 385 -- eXtreme Programming -- is XP used often

      I have no real data. XP had a lot of hype, and quite a bit of criticism in the last 8 years. I suspect that it is hardly ever done properly -- lots of enterprises will develop their on variations. XP is a very tight discipline. A very prescriptive set of practices. And there is no evidence that it scales up to distributed and outsourced processes.

      Chapter 20 pages 376-384 -- Design Code -- XP eXtreme Programming

      I can see the whole OO A/D process finally coming to the actual coding of software (the favorite part of any programmer); my question is on page 376 Larman mentions extreme programming, is this method of unit testing all production code useful? What if requirements change in the middle of coding? Would that make extreme programming less adaptable?

      Yes, XP has worked on many projects.

      It is also one of the best processes for handling change. Most if the XP practices are designed to handle requirements that change. Hence the title of Beck's book "Embrace Change". Examples: every week some change is made to the software and presented to the user. There is a user representative on the development team. Every week the user representative selects what needs to be done in the coming week from a menu of possible requirements. (I'd love to do a planning game exercise but we don't have time). Another XP practice is to have no documentation except code... so change is handled fast. Finally code is continuously refectored so that it is easy to change. There are more practices that are designed to provide very fast feedback and self-correction.

      For more check out [ Extreme_Programming ] in the Wikipedia.

      Chapter 21 pages 389 -- refactoring

      can you explain a situation where refactoring is used

      Think of refactoring as doing the laundry. Testing/modifying code tends to make it dirty, refactoring cleans it up. [Martin09]

      Whenever you have got to where the software passes all its tests you should take time to "refactor" it, repeating the tests after each small change. There is clear evidence in real projects that software "rusts" if not cleaned up on a regular basis.

      Chapter 21 pages 390 -- Code Smells

      Of the code smells listed in the book what is the worst smell? In what situations might some of these smells be okay?

      Duplicated code smells bad to me. But what smells worse is any code I can't understand by looking at it.

      Sometimes a complicated algorithm just can't be improved. It is me that has to change to understand it.

      Chapter 21 pages 389-392 -- Refactoring

      What are some methods of improving code smells? Some codes I(also many students) have written really stink!

      I agree....

      But refactoring does help. Look it up on the web! [ Refactoring ]

      Time to hit the books.... After this course is over?

      Chapter 25 pages 390 -- Generalize Relationship

      What is the generalize relationship? The book mentions it, but only to state that it's outside the scope of the introduction

      We will return to it later. It is the ---|> relation. It expresses (in the domain) the fact that one class of object is a special kind of another class. Example

    3. A cat is a special kind of pet.

      In a DCD it indicates the use of inheritance/extension. Example

       		Cat : public Pet { Sound sound(){return "Mew";} };
       		public class Cat extends Pet implements IMouser { ...}

      Chapter 22 pages 396 -- round trip engineering

      Can you better explain round trip engineering and how it is used?

      Disclaimer: I'm a cynic about this process.

      It was almost a slogan invented by Rational. If you have a tool that converts diagrams to code and code to diagrams then you can carry out the following process

      repeat (

      1. generate the code
      2. repeat (
        1. test the code
        2. modify the code
      3. until all tests pass or you get lost in the code
      4. regenerate the diagrams
      5. tidy up the diagrams

      How reliable are the unit testing frameworks in testing code

      From what I here from people that use them they are highly reliable -- but they rely on people writing good unit tests. Writing the tests takes skill and care. Using the tools is usually reported as fun and addictive.

      What do you do with objects that are created and then never do anything.

      Think more about them -- you've probably forgotten some obvious thing that they have to be able to do. For example: helping you print out results.

      A true dead-end object that is created and never used is probably incorrect.

      Chapter 21 pages 389-393 : Refactoring

      Refactoring seems more geared towards XP and agile UP. Would you even re-factor in a project where you aren't using XP/ agile UP? Wouldn't the purpose of all the design to prevent refactoring?

      Yes refactoring is now a vital part of XP. But it is a useful tool in most real projects.

      Even fragile projects that practice Big Design Up Front enter a maintenance phase. In this the code is changed -- sometimes for decades. If it isn't refactored then it rusts -- becomes badly designed, dangerous to change, and ultimately buggy.

      Notice that in theory we can get the design right on paper.... but in practice most projects have areas where you have to code a solution before you understand the problem enough to do the design. You now have a choice: (1) reverse engineer the diagrams and throw away your code... and then recode it. OR (2) refactor the working solution into a well-designed form.

      Chapter 21 pages 389-393 : Refactoring

      And, if you do refactor, would you go back and fix/change all the diagrams that would be effected by the refactoring?

      It depends on the degree of ceremony in the process. But to be rational the real question is to redraw when there is an obvious value to do so or it is cheap to do (by reverse engineering).

      Chapter All pages All : Real World

      In the real world, how much time would have passed in our project already?

      I guess about two weeks. I'm tempted to be nasty and make joke about only seeing about 2 or 3 days work so far:-)

      Warning: the next piece of assigned work (due next week) involves reworking and handing in a copy of everything... so I can see where your next iteration is starting from.

      Chapter 23 pages 402 : The Phases

      If a project is given 6 months to finish, how many weeks should be given to the second iteration. Should this iteration be more important then the first.

      The quick answer is that you don't really know until you've finished the first iteration. In other words, the plan you make at the start of the project is based on experience and guess work and must be revised as you learn more about the project and your team.

      This doesn't mean that you can't work out a set of iterations. Perhaps you should. The problem is that you are likely to be wrong. This may be why PERT is the Planning, estimation, and REEVALUATION Technique.

      Here is a simple technique: the team takes every feature and guesses how many days it will take to complete: analysis+design+code+integrate+test. Choose a collection of valuable and risky features that add up to say 3 weeks (15 days)work (say) and call this the first iteration. Now do it. How long did it take? Say it was 20 days! Now treat all your other estimates as needing 20/15 times what you planned. Start on another 15 day iteration and discover it take only 10 days ... faster take the original estimates and multiply them by 10/15 to get the next set of features.... MEANWHILE involve a user and other stakeholders in rethinking the features that want. There is nothing like running software to change your mind about what you really want!

      The other way to be sure is to allocate 3 weeks per iteration (a guess!) and then decide, at the start of each one what you expect to get done. Look up Scrum on the WWW!

      Note: There is no plan that is not project and team dependent.

    . . . . . . . . . ( end of section Questions on Visibility and moving from UML to Code) <<Contents | End>>

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.
  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  10. OO::shorthand="Object-Oriented".

  11. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  12. patterns::="Documented families of problems and matching solutions", see Patterns.
  13. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  14. Process::="How to develop software".

  15. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10.

  18. TBA::="To Be Announced".

  19. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  20. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  21. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need now. In this class it also means "It won't be on the final or in quizzes".

  22. XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.