I definitely enjoyed the whole experience of this class. I think if there was one more thing I would like to have learned, I think it would be function pointers. I don't think I quiet understood them. I have read online posts about function pointers, but they don't seem to click to me. I think downing does a great job of explaining things in general and I think I would gain from his explanations.
I was okay with the experience of blogging overall. I didn't have too much things that I wanted to blog about. I probably will not continue blogging after this class. But I'm glad I got the chance to know what it was like, because I did want to try blogging before but never got enough motivation to actually do it.
I definitely enjoyed the class. I think if I knew about it earlier, I would take his software engineering class, so I can get some experience in web programming. Unfortunately, I don't think I have any more room in my schedule for it.
Lastly, I'm much more comfortable with c++ now, I think I may be more comfortable then java. I remember when I was trying to show someone else how to code something, I default to c++ syntax.
I hope everyone else enjoyed the class, good luck on the final, and have a good break.
Saturday, December 3, 2011
Friday, December 2, 2011
Metrics Suite for Objected Oriented Design
This was an interesting paper, because I never knew there were metrics for software out there. I always just kind of thought software as something that is hard to judge, almost like an art piece. You can't really score an art piece, but make some observational comments about it. This paper talks about a new metric system to evaluate OOP designs.
The author attempts to improve previous metrics, because he believes previous metrics were not mathematically rigorous. Then he uses a metric defined by Weyuker to show that his metrics are better. However, I see there are still ways to go before metrics can become something that people can agree upon. The Weyuker's criterias uses notions of monotonicity, interaction, noncoarseness, nonuniqueness, and permutation. To show how these apply, he lists several examples. For example with nonuniqueness, it tries to capture the idea that two classes can have the same metric classes, meaning they are equally complex. The metric system cannot be such that all classes have different metric value. This is definitely useful in that a class has a different complexity even by having a different name. For example, two classes with the same function but different name (one a descriptive and another name a cryptic name) could have different metric value, and the nonuniqueness and noncoarseness would account for the value of the metric value. One of the criterion, I personally don't agree with which is monoticity. He means that given a class P, and a metric unit, u, u(P) <= u(P+Q), Q being another class. It is to measure that adding another class would only increase complexity. But I could think of instances where adding a class would demonstrate what the other classes are doing. For example, if class P was draw, and class Q was deckofcards, then it would make it obvious what the whole system was doing. While class P by itself makes the class ambiguous in terms of whether draw was referring to drawing a picture or drawing a card.
To determine the metrics, he uses Booch's outline of what are the essential features of object oriented programming. Booch listed them as: identification of classes, the semantics of classes, relationship between classes, and implementation of classes. Hence, all the metrics are centered around how the classes are defined and the relationship between the classes. He cites that the central them of OOP is classes, and that it is agreed upon by others though there are criticism of this. He does however admit that this system would not capture the dynamic behavior of the system, since it does not collect any information about the run time behavior.
For example, one of his metric was weighted methods per class. This is a number summing up all the complexities of each method in a class. He believes the higher the number it'll mean more time and effort to maintain the class, and larger number means more effect on children, and more methods mean very specific class. I don't think the way he determined the complexity of the methods is very rigorous.
Second metric: depth of inheritance tree. The basis for this metric is the scope of classes. How much the parent classes may affect the child classes. For example, if there is a great depth in the class hierarchy, then it is possible the child has a lot of methods that it inherited from the parents and it will become hard to predict how the child will behave. I think this is one of the best criterion for the oop metric. I think programmer often think in terms of 2 or 3 depth of inheritance, and after that I think people forget about the parents, so in a deep tree, I would forget what behaviors the child has inherited.
Third metric: number of children. This can suggest several things. The higher number of children will be good since there will many reuse of functions, but higher number of children also means the parent has to be extremely robust, and kind of suggest a strong single point of failure. It would indicate the need for perhaps breaking up the inheritance tree into different category to reduce the number of children.
Fourth metric: coupling between object classes. This means the how many classes a certain classes is attached or depends on. This could result in very bad programs and leading to highly unmodular design. If there is a change in one class, then all the classes that are coupled must also change in order to match that design. This metric is a good indicator of how maintainable the code will be in the long run. If there needs to be change everytime a small snippet changes, then it will be very hard to maintain the code. When the code really blows up, at certain point it will be beyond maintaining.
Fifth metric: response for a class. This refers to the idea of the set of responses a class can make to a message. This relates to idea of method overloading and dynamic binding between class hierarchies. For a particular message, if there are many methods that can be potentially be executed, then it makes it really hard to debug, and when the code gets large again, then it'll be really hard to figure out exactly what method is being called. Some of the worst bugs that I've had to deal with circles around this. I would be coding something and something behaves nothing like what I expected, then I start changing up the code to do something ridiculous and I get confused to why it won't change. Then I would have to trace the code even further to determine that it went on to call a different method than I expected. Not only does this increase in complexity, it also increase the run-time since the program has to determine which method to execute.
Last metric: lack of cohesion in methods. The way he determines cohesiveness between the methods is by looking at which local variable the method uses. The more local variables they share, the more cohesive these functions are. He suggests that if there is lack of cohesion, then the functions should be separated in to more subclasses because there isn't enough encapsulation. However, I don't particular agree with the reasoning, because from experience, I feel like there are instance when classes are well-defined but the method don't share too many local variables. I don't really know the reasoning for my statement. However, I can definitely understand how a class can be bloated when there is a different set of variables for each of the methods, and the entire program essentially being under one class.
These all have to do with how classes are defined. I think class definition are a very important point in oop design, but I think there can be many subtle things outside of class definition that could be useful for metrics. I think a lot of them are kind of common sense to programmers who have been programming for a decent amount of time. I think many people implicitly understand these concept and probably have even applied them during programming, but I think it is still useful to explicitly state and read about why decisions we make during class implementations matter. Overall the paper was pretty interesting, it opened me up to a topic that I didn't know existed, and it was interesting to read about how he collected the data to use against his metrics.
https://wwwbroy.in.tum.de/lehre/vorlesungen/vse/WS2004/1994_chambers_metric_suite_oo.pdf
The author attempts to improve previous metrics, because he believes previous metrics were not mathematically rigorous. Then he uses a metric defined by Weyuker to show that his metrics are better. However, I see there are still ways to go before metrics can become something that people can agree upon. The Weyuker's criterias uses notions of monotonicity, interaction, noncoarseness, nonuniqueness, and permutation. To show how these apply, he lists several examples. For example with nonuniqueness, it tries to capture the idea that two classes can have the same metric classes, meaning they are equally complex. The metric system cannot be such that all classes have different metric value. This is definitely useful in that a class has a different complexity even by having a different name. For example, two classes with the same function but different name (one a descriptive and another name a cryptic name) could have different metric value, and the nonuniqueness and noncoarseness would account for the value of the metric value. One of the criterion, I personally don't agree with which is monoticity. He means that given a class P, and a metric unit, u, u(P) <= u(P+Q), Q being another class. It is to measure that adding another class would only increase complexity. But I could think of instances where adding a class would demonstrate what the other classes are doing. For example, if class P was draw, and class Q was deckofcards, then it would make it obvious what the whole system was doing. While class P by itself makes the class ambiguous in terms of whether draw was referring to drawing a picture or drawing a card.
To determine the metrics, he uses Booch's outline of what are the essential features of object oriented programming. Booch listed them as: identification of classes, the semantics of classes, relationship between classes, and implementation of classes. Hence, all the metrics are centered around how the classes are defined and the relationship between the classes. He cites that the central them of OOP is classes, and that it is agreed upon by others though there are criticism of this. He does however admit that this system would not capture the dynamic behavior of the system, since it does not collect any information about the run time behavior.
For example, one of his metric was weighted methods per class. This is a number summing up all the complexities of each method in a class. He believes the higher the number it'll mean more time and effort to maintain the class, and larger number means more effect on children, and more methods mean very specific class. I don't think the way he determined the complexity of the methods is very rigorous.
Second metric: depth of inheritance tree. The basis for this metric is the scope of classes. How much the parent classes may affect the child classes. For example, if there is a great depth in the class hierarchy, then it is possible the child has a lot of methods that it inherited from the parents and it will become hard to predict how the child will behave. I think this is one of the best criterion for the oop metric. I think programmer often think in terms of 2 or 3 depth of inheritance, and after that I think people forget about the parents, so in a deep tree, I would forget what behaviors the child has inherited.
Third metric: number of children. This can suggest several things. The higher number of children will be good since there will many reuse of functions, but higher number of children also means the parent has to be extremely robust, and kind of suggest a strong single point of failure. It would indicate the need for perhaps breaking up the inheritance tree into different category to reduce the number of children.
Fourth metric: coupling between object classes. This means the how many classes a certain classes is attached or depends on. This could result in very bad programs and leading to highly unmodular design. If there is a change in one class, then all the classes that are coupled must also change in order to match that design. This metric is a good indicator of how maintainable the code will be in the long run. If there needs to be change everytime a small snippet changes, then it will be very hard to maintain the code. When the code really blows up, at certain point it will be beyond maintaining.
Fifth metric: response for a class. This refers to the idea of the set of responses a class can make to a message. This relates to idea of method overloading and dynamic binding between class hierarchies. For a particular message, if there are many methods that can be potentially be executed, then it makes it really hard to debug, and when the code gets large again, then it'll be really hard to figure out exactly what method is being called. Some of the worst bugs that I've had to deal with circles around this. I would be coding something and something behaves nothing like what I expected, then I start changing up the code to do something ridiculous and I get confused to why it won't change. Then I would have to trace the code even further to determine that it went on to call a different method than I expected. Not only does this increase in complexity, it also increase the run-time since the program has to determine which method to execute.
Last metric: lack of cohesion in methods. The way he determines cohesiveness between the methods is by looking at which local variable the method uses. The more local variables they share, the more cohesive these functions are. He suggests that if there is lack of cohesion, then the functions should be separated in to more subclasses because there isn't enough encapsulation. However, I don't particular agree with the reasoning, because from experience, I feel like there are instance when classes are well-defined but the method don't share too many local variables. I don't really know the reasoning for my statement. However, I can definitely understand how a class can be bloated when there is a different set of variables for each of the methods, and the entire program essentially being under one class.
These all have to do with how classes are defined. I think class definition are a very important point in oop design, but I think there can be many subtle things outside of class definition that could be useful for metrics. I think a lot of them are kind of common sense to programmers who have been programming for a decent amount of time. I think many people implicitly understand these concept and probably have even applied them during programming, but I think it is still useful to explicitly state and read about why decisions we make during class implementations matter. Overall the paper was pretty interesting, it opened me up to a topic that I didn't know existed, and it was interesting to read about how he collected the data to use against his metrics.
https://wwwbroy.in.tum.de/lehre/vorlesungen/vse/WS2004/1994_chambers_metric_suite_oo.pdf
Sunday, November 27, 2011
Weekly Blog #13
I hope everyone had a good thanksgiving. I definitely had a good time at home spending time with my family and getting to eat some good food. I took some work home and didn't get anything done. Now I have so much work to look forward to now.
It is so hard to believe that this semester will be over in just a week, then just finals. Luckily, I have a very light finals week schedule.
I'm so glad we didn't have to do any project over the break. I think it would have been just painful getting to organize meeting with a partner, and it is hard to just get stuff done over the break in general when I am at home. I am already looking forward to the winter break.
Just looking back, I don't think I ever wanted to miss this class on purpose. I may have missed a few due to oversleeping, but I never thought to myself that I didn't want to go because the lectures were useless. I felt like the lectures were always useful and I could get most or all the information that I needed just from the lecture. Often, I feel like the lectures go over my head, and I miss a lot of stuff unless I go through the book. However, I felt like materials were explained very clearly in the class. I sometimes wish I took notes because I don't understand what he put some of the codes on the slides, the comments help, but sometimes there are no comments.
Monday, November 21, 2011
Weekly Blog #12
It feels pretty good not to have a project in this class anymore. Overall I think this class had a very fair amount of homework. I think the ratio of how much I learned in this class to how much work was needed is huge. I think downing is definitely a good lecturer and I am definitely glad I took this class. I kind of wish I took this class little earlier in college so I can have these, what seems to be basic, knowledge. I'm surprised how much basic knowledge I was missing.
The handle class lessons are pretty interesting, I guess people use this tactic to protect against pointer bugs since it can almost impossible to debug in a huge program.
One really important thing I learned in this class is regarding blogs. I've read some of Joel's blogs before, but just once in a while, but since we read it quiet often in this class, I found myself going to his site myself to read some of his other blogs. Then I ran into some other blogs by other well-known software engineer bloggers. I've definitely come across good writers and across good and interesting ideas. I definitely can broaden my perspectives and learn a lot more and efficiently by reading what other people are thinking and are doing.
The handle class lessons are pretty interesting, I guess people use this tactic to protect against pointer bugs since it can almost impossible to debug in a huge program.
One really important thing I learned in this class is regarding blogs. I've read some of Joel's blogs before, but just once in a while, but since we read it quiet often in this class, I found myself going to his site myself to read some of his other blogs. Then I ran into some other blogs by other well-known software engineer bloggers. I've definitely come across good writers and across good and interesting ideas. I definitely can broaden my perspectives and learn a lot more and efficiently by reading what other people are thinking and are doing.
Sunday, November 13, 2011
Weekly Blog #11
One thing I wanted to find out from blogging was whether I would like it. I don't think I like it too much, I don't find myself wanting to post something in a blog. I am only reminded weekly from everyone's posting that I need to do it for the extra credit. I probably will not continue blogging after this class, but I'm glad I got to try it.
I'm glad we don't have any more project after thanksgiving for this class. It is a nice break. I think the class stuff is getting more difficult, I wish I took some notes, because I am not able to recall everything from his codes anymore. The paper on gender difference was interesting, but I didn't think any of the findings were surprising at all.
As thanksgiving approaches, I was just thinking about the things I'm thankful for, and I'm really thankful for the opportunity to be at UT and studying here. I feel like it is so much hard work, but I often forget that it is a privilege to be studying at a university. I'm glad for the great faculty and the great cs program, at the end of it all, I do like what I'm learning and I'm really thankful that I get to be here.
I'm glad we don't have any more project after thanksgiving for this class. It is a nice break. I think the class stuff is getting more difficult, I wish I took some notes, because I am not able to recall everything from his codes anymore. The paper on gender difference was interesting, but I didn't think any of the findings were surprising at all.
As thanksgiving approaches, I was just thinking about the things I'm thankful for, and I'm really thankful for the opportunity to be at UT and studying here. I feel like it is so much hard work, but I often forget that it is a privilege to be studying at a university. I'm glad for the great faculty and the great cs program, at the end of it all, I do like what I'm learning and I'm really thankful that I get to be here.
Sunday, November 6, 2011
Weekly Blog #10
Only one more project left in this class and we are done. I'm glad there is not a project due after thanksgiving. Time really does goes by fast as you grow older. I feel like freshmen year I did so much stuff, but now I feel like I'm not doing as much and time is just going by faster. I heard someone once wisely said "when you are young, each moment makes a big portion of your life, but when you are older, each moment is grows smaller and smaller in significance due to all your previous moments." It was something like that I don't know if he took it from someone, I wish I knew what the exact quote was if he did take it from some book or something.
This was my first time using piazza, from what I heard a lot of cs professors use it, but that was not the case for me. I had a very good experience with it, I really enjoyed how there was a live audience who would listen to your problems and answer them and help you through problems. I also liked the fact that the professor visited the page frequently to answer question in a timely manner. I wish I had something like piazza in some of my class from freshmen year when I had so much trouble understand everything. Sometimes the skeleton that was provided would be buggy, and I would spend all night trying to fix my code and only to find out near the due date that it was the skeleton. Sometimes asking questions to friends would help but sometimes your friend might not have gotten far enough to reach that problem. So I feel like piazza was really good, because different people will work on the project earlier throughout the semester and we can help each other if you happened to start early.
This was my first time using piazza, from what I heard a lot of cs professors use it, but that was not the case for me. I had a very good experience with it, I really enjoyed how there was a live audience who would listen to your problems and answer them and help you through problems. I also liked the fact that the professor visited the page frequently to answer question in a timely manner. I wish I had something like piazza in some of my class from freshmen year when I had so much trouble understand everything. Sometimes the skeleton that was provided would be buggy, and I would spend all night trying to fix my code and only to find out near the due date that it was the skeleton. Sometimes asking questions to friends would help but sometimes your friend might not have gotten far enough to reach that problem. So I feel like piazza was really good, because different people will work on the project earlier throughout the semester and we can help each other if you happened to start early.
Sunday, October 30, 2011
Weekly Blog #9
I have done the darwin's world project before except it was called critter world or something. From what I can remember it was almost exactly the same except there were more instructions. I did it in java and our professor provided a skeleton for us so all we had to write was an interpreter. I remember in that class he also provided a graphical simulator where we can actually see all the little critters (species) move around and attack each other. They all had different colors and I think all the critters were shaped as a triangle.
I've been looking around in my free time for a little bit to pick a paper to write a blog about, but I haven't had a chance to find a good that was related to the class. Did anyone have any luck with this?
Now I feel like we are really going deep into the details of c++, I'm not sure how much of it is related object oriented programming as the class name suggests. It seems like we are going more into design tradeoffs between java and c++. I still think it is useful, since I didn't know most of the stuff before. I'm just really looking forward to thanksgiving at this point, and hope everyone had a safe Halloween.
I've been looking around in my free time for a little bit to pick a paper to write a blog about, but I haven't had a chance to find a good that was related to the class. Did anyone have any luck with this?
Now I feel like we are really going deep into the details of c++, I'm not sure how much of it is related object oriented programming as the class name suggests. It seems like we are going more into design tradeoffs between java and c++. I still think it is useful, since I didn't know most of the stuff before. I'm just really looking forward to thanksgiving at this point, and hope everyone had a safe Halloween.
Subscribe to:
Posts (Atom)