How would you initialize the child class from the base classes' parameterized constructor.

Constructor in C#

a great article on the inheritence in c#. This article is equipped with really kool and understandable code and discussion. Those wanting to get a complete introduction must read this out.


Virtual Functions - new and override - C# The Basics - Beta2

Have you ever wanted to strip all of the HTML tags from a string? There are many reasons you may want to do this. For example, if you provide a feature on your site where a user can have the contents of a Web page emailed to them, you may wish to strip all of the HTML tags from the particular article for those users whose email client does not support HTML-formatted email.


Function stripHTML(strHTML)
'Strips the HTML tags from strHTML using split and join

'Ensure that strHTML contains something
If len(strHTML) = 0 then
stripHTML = strHTML
Exit Function
End If

dim arysplit, i, j, strOutput

arysplit = split(strHTML, "<") 'Assuming strHTML is nonempty, we want to start iterating 'from the 2nd array postition if len(arysplit(0)) > 0 then j = 1 else j = 0

'Loop through each instance of the array
for i=j to ubound(arysplit)
'Do we find a matching > sign?
if instr(arysplit(i), ">") then
'If so, snip out all the text between the start of the string
'and the > sign
arysplit(i) = mid(arysplit(i), instr(arysplit(i), ">") + 1)
else
'Ah, the < stroutput =" join(arysplit," stroutput =" mid(strOutput,"> to < and >
strOutput = replace(strOutput,">",">")
strOutput = replace(strOutput,"<","<")

stripHTML = strOutput
End Function

How to fix bugs in the Live / Production environment - The Code Project - Design and Strategy

Google Groups : microsoft.public.inetserver.iis

A use case is a sequence of actions that provide a measurable value to an actor. Another way to look at it is a use case describes a way in which a real-world actor interacts with the system. In a system use case you include high-level implementation decisions. System use cases can be written in both an informal manner and a formal manner. Techniques for identifying use cases are discussed as well as how to remain agile when writing use cases.

Informal System Use Cases

Introduction to System Use Cases

Building Object Applications: Your Step-By-Step Handbook for Developing Robust Systems Using Object Technology

The Full-Lifecycle Object-Oriented Testing (FLOOT) methodology is a collection of testing techniques to verify and validate object-oriented software. The FLOOT lifecycle is depicted in, indicating a wide variety of techniques are available to you throughout all aspects of software development. The list of techniques is not meant to be complete – instead the goal is to make it explicit that you have a wide range of options available to you. It is important to understand that although the FLOOT method is presented as a collection of serial phases it does not need to be so: the techniques of FLOOT can be applied with evolutionary/agile processes as well. The reason why I present the FLOOT in a “traditional” manner is to make it explicit that you can in fact test throughout all aspects of software development, not just during coding.

Read more about The Full Life Cycle Object-Oriented Testing (FLOOT) Method

A fundamental concept of the Unified Modeling Language (UML) is that you use different diagrams for different purposes. Class diagrams are used to model the static nature of your system, sequence diagrams are used to model sequential logic, and state machine diagrams are used to model the behavior of complex classes. But what happens when you need to show the behavior of several objects collaborating together to fulfill a common purpose? This is what UML communication diagrams, formerly known as collaboration diagrams in UML 1.x, can be used for because they provide a birds-eye view of a collection of collaborating objects.

Communication diagrams show the message flow between objects in an OO application and also imply the basic associations (relationships) between classes. Figure 1 presents a simplified collaboration diagram for displaying a seminar details screen or page. The rectangles represent the various objects involved that make up the application. The lines between the classes represent the relationships (associations, composition, dependencies, or inheritance) between them. The same notation for classes and objects used on UML sequence diagrams are used on UML communication diagrams, another example of the consistency of the UML. The details of your associations, such as their multiplicities, are not modeled because this information is contained on your UML class diagrams: remember, each UML diagram has its own specific purpose and no single diagram is sufficient on its own. Messages are depicted as a labeled arrow that indicates the direction of the message, using a notation similar to that used on sequence diagrams.

Figure 1



Figure 2 summarizes the basic notation for modeling messages on communication diagrams. Optionally, you may indicate the sequence number in which the message is sent, indicate an optional return value, and indicate the method name and the parameters (if any) passed to it. Sequence numbers should be in the format A.B.C.D to indicate the order in which the messages where sent. In Figure 1 message 1 is sent to the Seminar object which in turn sends messages 1.1 and then 1.2 to the Course object. Message 5 is sent to the Seminar object, which sends message 5.1 to enrollment, which in turn sends message 5.1.1 to student, and it finally sends message 5.1.1.1 to itself. Notice how a recursive connection, or a self connection, is required so that student can do this.
Although Figure 1 applies sequence numbers to the messages, my experience is if you feel the need to use sequence numbers on communication diagrams this is a good indication you should be using sequence diagrams instead. The main difference between communication diagrams and sequence diagrams is that sequence diagrams are good at showing sequential logic but not that good at giving you a “big picture view” whereas communication diagrams are the exact opposite.

Figure 2. Message notation.
[sequenceNumber:] methodName(parameters) [: returnValue]

In you see the Seminar Details user interface object collaborates with the seminar object to obtain the information needed to display its information. It first invokes the getter method to obtain the name of the seminar. To fulfill this responsibility, the seminar object then collaborates with the course object that describes it to obtain the name of the course. In this example I showed return values for some messages but not others to provide examples of how to do it. I’ll either indicate the type of the return value, for example string, or the result, such as seminarName. Normally I wouldn’t show return values on this diagram because the messages are named well – my heuristic is to only model return values when it isn’t clear what the message returns. Better yet I try to find a new name for the message (remember, messages map to operations implemented by your classes).

Another trick I often use is to consolidate trivial messages such as getter invocations. In I modeled the series of getter method invocations to obtain the information needed to display the list of students enrolled in a seminar as the single message getInfo. I also added a note to the diagram to make it clear what I was doing, but I typically don’t do that. Why is this important? Because agile developers will only do things that add value, and defining an exact list of getter invocations wouldn’t have added value.

You draw communication diagrams in the same way as you draw sequence diagrams, the only real difference is that you lay out the notation in a different manner. To tell you the truth I rarely find the need to create communication diagrams although I have found them useful in situations where we didn’t have use cases as the primary requirements artifact. Sequence diagrams and use cases seem to go hand in hand because of how easy it is to model the sequential logic of a use case using a sequence diagram. Communication diagrams seem to be preferred by people with a “structure bent”, people that focus on UML class diagrams or class responsibility collaborator (CRC) cards, because of the similarity of communication diagrams with those types of artifacts. As always, follow the AM practice Apply the Right Artifact(s) and use the most appropriate technique for your situation.

Project documentation and analysis is the most important part of any project. Without a proper analysis, any project takes more time to develop, is not robust, there's no way to find out if all the milestones have been met. trouble always awaits if a project starts without proper analysis. I have always had interest in analyzing the projects properly although have not been much interested in reading huge books. I want to read all the books about all the tech stuff but it is not humanly possible to read them, now i think no one takes time out to read out something especially when a person works, studies and does a lot of work at the same time.

ah... everyone has a different perspective of life, what can anyone say about anyones lifestyle or priorities!!!

This is an interesting article, would like people to read it out. The link describes what a UML 2 class diagram is in a very precise short and to the point manner.
Introduction to UML 2 Class Diagrams