software engineering chapte r one Btech

Editor's Notes

• #8: What is Software Engineering? The goal is to produce high quality software to satisfy a set of functional and nonfunctional requirements. How do we do that? First, and foremost, by acknowledging that it is a problem solving activity. That is, it has to rely on well known techniques that are used all over the world for solving problems. There are two major parts of any problem solving process: Analysis: Understand the nature of the problem. This is done by looking at the problem and trying to see if there are subaspects that can be solved independently from each other. This means, that we need to identify the pieces of the puzzle (In object-oriented development, we will call this object identification). Synthesis: Once you have identified the pieces, you want to put them back together into a larger structure, usually by keeping some type of structure within the structure. Techniques, Methodologies and Tools: To aid you in the analysis and synthesis you are using 3 types of weapons: Techniques are well known procedures that you know will produce a result (Algorithms, cook book recipes are examples of techniques). Some people use the word “method” instead of technique, but this word is already reserved in our object-oriented development language, so we won’t use it here. A collection of techniques is called a methodology. (A cookbook is a methodology). A Tool is an instrument that helps you to accomplish a method. Examples of tools are: Pans, pots and stove. Note that these weapons are not enough to make a really good sauce. That is only possible if you are a good cook. In our case, if you are a good software engineer. Techniques, methodologies and tools are the domain of discourse for computer scientists as well. What is the difference?
• #10: A computer scientist assumes that techniques, methodologies and tools are to be developed. They investigate in designs for each of these weapons, and prove theorems that specify they do what they are intended to do. They also design languages that allow us to express techniques. To do all this, a computer scientist has available an infinite amount of time. A software engineering views these issues as solved. The only question for the software engineer is how these tools, techniques and methodologies can be used to solve the problem at hand. What they have to worry about is how to do it under the time pressure of a deadline. In addition they have to worry about a budget that might constrain the solution, and often, the use of tools. Good software engineering tools can cost up to a couple of $10,000 Dollars (Galaxy, Oracle 7, StP/OMT) Object modeling is difficult. As we will see, good object modeling involves mastering complex concepts, terminology and conventions. It also requires considerable and sometimes subjective expertise in a strongly experience-based process. Beware of the false belief that technology can substitute for skill, and that skill is a replacement for thinking. offers this advise [cit Tillmann]. Many organizations are frustrated with a lack of quality from their tool-based systems. However, the cause of this problem is often the false belief that a tool can be a substitute for knowledge and experience in understanding and using development techniques. Although CASE tools such as StP/OMT or Objectory and similar tools have the potential to change how people design applications, it is a mistake to think they can replace the skills needed to understand and apply underlying techniques such as object, functional or dynamic modeling. You cannot substitute hardware and software for grayware (brain power) [cit Tillmann]: Buying a tool does not make a poor object modeler a good object modeler. Designers need just as much skill in applying techniques with CASE tools as they did with pen and paper. Another problem, that is often associated with tool-based analysis is that it is often insufficient or incomplete. Why is that? To a certain extent this problem has always existed. Systems developers are much better at collecting and documenting data than they are at interpreting what these data mean. This in unfortunate, because the major contribution an analysist can bring to system development is the thought process itself. But just as a tool is not a substitute for technique, knowledge and experience, technique skills cannot replace good analysis - people are still needed to think through the problem. So our message is: Being able to use a tool does not mean you understand the underlying techniques, and understanding the techniques does not mean you understand the problem. In the final analysis, organizations and practitioners must recognize, that methodologies, tools and techniques do not represent the added values of the object modeling process. Rather, the real value that is added, is the thought and insight that only the analyst can provide.
• #14: Hierarchy (Booch 17): Object model is called object structure by Booch
• #20: Which decomposition is the right one? If you think you are politically correct, you probably want to answer: Object-oriented. But that is actually wrong. Both views are important Functional decomposition emphasises the ordering of operations, very useful at requirements engineering stage and high level description of the system. Object-oriented decomposition emphasizes the agents that cause the operations. Very useful after initial functional description. Helps to deal with change (usually object don’t change often, but the functions attached to them do).
• #25: Because of the ambiguity of the picture we can model it in several ways: > As a bitmap of black and white pixels > As an eskimo entering a cave > As the portraint of an Indian with closed eyes Which one is the correct model? We don’t know as long as we don’t know the application domain. Here is an important example where we should consult application domain experts and end users. However, even the expert should not be relied on being able to explain to you all the objects of the application domain. User-centered analysis means that we interactively (in a dialectic way) explore the objects of the application domain. A good way to approach this discussion is to start with one or more object models as hypotheses. (It is important here to stress the fact that they are hypotheses, that are to be improved (by enhancements or starting from scratch) in an incremental and iterative (dialective) way. For example, in the above case, the object modeler might prepare two object models: That there is a face (we don’t see it in the picture), that the face has two ears and a mouth Note: Sometimes the application domain is obvious and one could argue that it is not necessary to create more than one object model. However, presenting the two or three possible object models has an important advantage: It might show the involved parties (developers, application domain expert and end user) that the application domain has ambigious objects. For that reason it is also important not to go into too much depth in the formulation of the first object model version. The above object models might be enough to disambiguate the problem statement. If it is decided that the picture actually presents an eskimo that more in depth object modeling is appropriate.
• #26: At this stage of the analysis we concentrate on the living conditions for the eskimo. In particular, the attribute entrance turns out to be very important, because the Cave has more than one entrance each of them with different dynamic behavior. During a blizzard, the cave is entered only through one of the wind holes which are not in the direction the wind is blowing, whereas during calm periods the Cave is entered during the MainEntrance. The shape of the windhole is a circle, whereas the MainEntrance is a rectangle. Note that due to the inheritance we do not model that there are many Windholes and only one MainEntrance. According to the object model shown, there can be many MainEntrances as well. We also start modeling the Outside, where the Temparature, the Light and the Season are important attributes which determine whether the Eskimo is hunting or getting some order in the cave.
• #27: In this object model we have decided to model an indian head. We now consider the mouth and the ears to be important objects with their own dynamic behavior instead of just being static attributes of a face and that the person does most of the work with his ears and mouth where the size are important. This means that we create two more objects, Ear and Mouth. Theses classes are created by removing the attributes from the Face class in the previous picture and making them parts of the Face class by connecting them with aggregate associations. The model also contains 2 hypotheses: That the face has two ears and one mouth. This knowledge comes from our general knowledge, not from the application domain, and it is therefore important to verify this fact.
• #31: The identification of objects and the definition of the system boundary are heavily intertwined with each other.