oops concepts for C++ language to understand basics

Editor's Notes

• #4: Users of software programs are isolated from the logic needed to accomplish a task. For example, when you print a page in your word processor, you initiate the action by clicking a print button. You are isolated from the internal processing that needs to occur; you just wait for a response telling you if it printed. Internally, the button object interacts with a printer object, which interacts with the printer to accomplish the task of printing the page. OOP concepts started surfacing in the mid-1960s with a programming language called Simula and further evolved in the 1970s with advent of Smalltalk. Although software developers did not overwhelmingly embrace these early advances in OOP languages, object-oriented methodologies continued to evolve. A resurgence of interest in object-oriented methodologies occurred in the mid-1980s. Specifically, OOP languages such as C++ and Eifle became popular with mainstream computer programmers. OOP continued to grow in popularity in the 1990s, most notably with the advent of Java and the huge following it attracted. And in 2002, in conjunction with the release of the .NET Framework, Microsoft introduced a new OOP language, C# (pronounced C-sharp) and revamped Visual Basic so that it is truly an OOP language.
• #6: In addition to these shortcomings, some evolutions of computing systems caused further strain on the structural program approach: Nonprogrammers demanded and were given direct access to programs through the incorporation of graphical user interfaces and their desktop computers. Users demanded a more-intuitive, less-structured approach to interacting with programs. Computer systems evolved into a distributed model where the business logic, user interface, and backend database were loosely coupled and accessed over the Internet and intranets.
• #8: Booch defines an object as
• #46: In many diagrams, the bottom two compartments are omitted. Even when they are present, they typically do not show every attribute and operations. The goal is to show only those attributes and operations that are useful for the particular diagram. This ability to abbreviate an icon is one of the hallmarks In many diagrams, the bottom two compartments are omitted. Even when they are present, they typically do not show every attribute and operations. The goal is to show only those attributes and operations that are useful for the particular diagram. This ability to abbreviate an icon is one of the hallmarks
• #48: Notice that each member variable is followed by a colon and by the type of the variable. If the type is redundant, or otherwise unnecessary, it can be omitted. Notice also that the return values follow the member functions in a similar fashion. Again, these can be omitted. Finally, notice that the member function arguments are just types. I could have named them too, and used colons to separate them from their types;
• #51: In UML relationships are presumed to be bidirectional unless the arrowhead is present to restrict them.
• #54: In this diagram we see that Circle and Square both derive from Shape . Note that the name of class Shape is shown in italics. This indicates that Shape is an abstract class. Note also that the operations, Draw() and Erase() are also shown in italics. This indicates that they are pure virtual.
• #55: It takes a “single section” approach to classes, instead of the three section approach that we’ve seen in previous diagrams, because we’re exploring relationships between entity types but not their responsibilities. It uses UML 2.0’s generalization set concept, basically just an inheritance arrowhead with a label representing the name of the set.  In UML 1.x this label was called a discriminator.  There are three generalization sets for Person: Nationality, Role, and Gender.  These generalization sets overlap – a person can be classified via each of these roles (e.g. someone can be a male foreign student).  This is called multiple classification.  You can indicate “sub generalization” sets, for example Student within the Role generalization set.   Some generalization sets are mutually exclusive from others, not shown in the example, where an entity type may only be in one set.  This is referred to as single classification and would be modeled using an XOR (exclusive OR) constraint between the two (or more) discriminators.  
• #59: Suppose that this function takes an argument of type DrawingContext.
• #61: Note the «type» string at the top of the class. The two surrounding characters “«»” are called guillemets (pronounced Gee-may). A word or phrase surrounded by guillemets is called a “stereotype”. Stereotypes are one of the mechanisms that can be used to extend UML. When a stereotype is used above the name of a class it indicates that this class is a special kind of class that conforms to a rather rigid specification. The «type» stereotype indicates that the class is an interface. This means that it has no member variables, and that all of its member functions are pure virtual. UML supplies a shortcut for «type» classes. Figure 9 shows how the “lollypop” notation can be used to represent an interface. Notice that the dependency between Shape and DrawingContext is shown as usual. The class WindowsDC is derived from, or conforms to, the Drawingcontext interface.
• #62: The association relationship indicates that (at least) one of the two related classes makes reference to the other. In contrast with the generalization relationship, this is most easily understood through the phrase 'A has a B' {a mother cat has kittens, kittens have a mother cat}.
• #70: The light blue vertical rectangles the objects activation while the green vertical dashed lines represent the life of the object.  The green vertical rectangles represent when a particular object has control.  The represents when the object is destroyed.  This diagrams also shows conditions for messages to be sent to other object.  The condition is listed between brackets next to the message.  For example, a [condition] has to be met before the object of class 2 can send a message() to the object of class 3.  
• #71: The object an Order Entry Window is created and sends a message to an Order object to prepare the order. Notice the the names of the objects are followed by a colon.  The names of the classes the objects belong to do not have to be listed.  However the colon is required to denote that it is the name of an object following the objectName:className naming system. Next the Order object checks to see if the item is in stock and if the [InStock] condition is met it sends a message to create an new Delivery Item object.
• #74: .  This time the names of the objects appear after the colon, such as :Order Entry Window following the objectName:className naming convention. This time the class name is shown to demonstrate that all of objects of that class will behave the same way.
• #80: The diagram below shows a super-state.  Both the Checking and Dispatching states can transition into the Canceled state, so a transition is shown  from a super-state named Active to the state Cancel.  By contrast, the state Dispatching can only transition to the Delivered state, so we show an arrow only from the Dispatching state to the Delivered state.