Finding a column from the database
select * from syscolumns where name ='empid'
Finding an object from database
Select * from sysobjects where name='employee'
Finding the table name to which the column belongs
select * from sysobjects where id in(select id from syscolumns where name like'empid%'
Getting displayed the columns and tables to gather
Select a.name, b.name from sysobjects a, syscolumns b
Where a.id = b.id
In this Chapter we will take a good long look at fuzzy logic, and a brief look at fuzzy sets and fuzzy numbers. (Later chapters will look more deeply into fuzzy sets and fuzzy numbers.)
1.1 Fuzzy Logic.
In conventional logic, a statement is either true or false, with nothing in between. This principle of true or false was formulated by Aristotle some 2000 years ago as the Law of the Excluded Middle, and has dominated Western logic ever since.
Fuzzy logic offers a better way of representing reality. In fuzzy logic, a statement is true to various degrees, ranging from completely true through half-truth to completely false.
The basic idea of multi-valued logic has been explored to some extent by a number of mathematicians in this century, but the real breakthrough was made by Prof. Lotfi Zadeh of the University of California in Berkeley. In 1965 he published a paper on the theory of fuzzy sets; that paper has given rise to hundreds of papers on fuzzy mathematics and fuzzy systems theory. Most importantly, fuzzy theory was adopted wholeheartedly by the Japanese, and their advances in the field of fuzzy control have won the attention of engineers throughout the world. Fuzzy theory gives us a whole new approach to the mathematics of thinking; it is a change of paradigm for Western world scientists and mathematicians, and like all changes of paradigm has been initially strenuously resisted, except in the Far East, where two-valued Aristotelian logic has not been too deeply ingrained.
The computer tool which your knowledge engineer will be using for expert system development is FLOPS (Fuzzy LOgic Production System), developed originally in the early 1980's at the Kemp-Carraway Heart Institute by Douglas Tucker and William Siler for medical image analysis.
FLOPS is based on fuzzy systems theory: fuzzy logic; fuzzy sets; and fuzzy numbers. The use of fuzzy mathematics gives FLOPS some important advantages. It is possible to reason in terms of words, such as small, medium, fast, slow and so on, rather than in terms of numbers; ambiguities and contradictions can be easily handled; and uncertainties pose no problems.
In this chapter we will consider fuzzy logic, with a continuous gradation of truth values ranging from false to true. We define the truth of a statement or value as being the confidence we have that the statement or value is correct. Truth is measured numerically; in most fuzzy systems literature, as ranging from zero (false) to one (true). FLOPS uses a different scale; confidences in FLOPS range from 0 (false) to 1000 (true), since this scale economizes computer memory requirements. This difference in scale is sufficiently obvious.
I have defined what truth is for a single statement. But now consider the truth of the combination of two statements, A AND B. A and B are both assertions; for example, Ashok is a man, or I don't have much free time this week. In conventional logic, of course both A and B must be either true or false. The statement (A AND B) is true only if both A and B are individually true; otherwise, the statement (A AND B) is false. Now, how do we define the fuzzy truth value of the statement (A AND B) if the fuzzy truth values of A and B separately are known? Fuzzy logic gives a remarkably simple answer to this problem: the truth of (A AND B) together is the minimum of the truth value of A and the truth value of B.
Similarly, consider the statement (A OR B), which in conventional logic is true if statement A or statement B or both are true, and is only false if both A and B are false. In fuzzy logic, the truth of (A OR B) is simply the maximum of the truth value of A and the truth value of B.
It is hard to see the practical importance of these simple rules of logic by themselves. However, most Western reasoning has its foundation in logic; these simple but new rules of logic have great impact on patterns of reasoning. And it is with patterns of reasoning that we are most concerned in constructing expert systems; it is patterns of real-life productive human reasoning that we are trying to emulate. Fuzzy logic gives us the theoretical tools to do this.
Fuzzy Sets
In mathematics, the concept of set is very simple, but very important. A set is simply a collection of things. The things can be most anything you want - numbers, names of autos, you name it. Things either belong to the set or don't belong, similar to the idea in logic that statements are either true or false. In 1965, Lotfi Zadeh proposed the idea of a fuzzy set; a fuzzy set is one to which objects can belong to different degrees, called grades of membership. in FLOPS, we measure the confidence that the member belongs to the fuzzy set as a number ranging from zero (absolutely false) to 1000 (absolutely true). One of my favorite fuzzy sets comes from the TV show MASH:
Character | Fuzzy Sets: | |
Men | Athletes | |
Hawkeye | 1000 | 500 |
BeeGee | 1000 | 750 |
Lt.Col. Penobscot | 1000 | 1000 |
Hot Lips Hooli han | 0 | 950 |
Klinger | 900 | 250 |
This simple idea of different grades of membership in a fuzzy set is extremely helpful in constructing expert systems. We will be concerned with fuzzy sets of descriptive words, where the grade of membership represents our confidence that the descriptor is true of whatever we are considering. Usually, we will use the term confidence rather than grade of membership. This permits us to use ordinary language in describing things in a precise way.
As an example, consider a fuzzy set speed, with members Slow, Medium and Fast.
Of course, we have to define in some way how to go back and forth between the description of speed in numbers and the description of speed in words. This is done through defining membership functions, which look something like this: Of course, different experts would have different feelings about what speeds should be classified as Fast, Medium or Slow. Leaving a good deal of overlap on the adjacent membership functions is a very good idea; it lends robustness to the reasoning system. Membership functions need not be made up of straight lines; curvilinear shapes are available. Other useful fuzzy sets are not descriptions of numbers, but of (in a broad sense) categories. These fuzzy sets are not word descriptors of "how much", but are answers to "what is it?" For example, fuzzy set color might have members Red, Green and Blue. Fuzzy set car might have members Ford, Chevrolet, Toyota and Buick. In fuzzy sets like speed and color it is very likely that two or more descriptors might have non-zero confidences at the same time; that is fine, since we are seldom certain that one descriptor is entirely right and the others are entirely wrong. These are ambiguities, and as mentioned above they lend strength to the reasoning process. But in other fuzzy sets like car, it is not possible for a car to be both a Buick and a Chevrolet. In this case, if more than one member has a non-zero confidence, we have a contradiction. Contradictions need to be resolved before leaving our program, often by examining more data. 1.3 Fuzzy Numbers. The final major member of our fuzzy systems arsenal is the fuzzy number. A fuzzy number is simply an ordinary number whose precise value is somewhat uncertain. Here, for example, is a fuzzy two. Here our confidence that numbers 1.5 or less belong to the fuzzy 2 is zero, as is our confidence that numbers 2.5 or greater belong to the fuzzy 2. Our confidence that 1.6 belongs to the fuzzy 2 is 200; for 1.7, 400; and so on to confidence 1000 for 2. For numbers greater than 2, the confidence declines as the number increases, being 800 for 2.1, 600 for 2.2, and so on to zero confidence for 2.5. A very convenient way to describe fuzzy numbers is to use modifying words. For example, the fuzzy two shown in Figure 1 could be completely specified by "roughly 2". Other modifying words available are "nearly", "about" and "crudely", with progressively larger uncertainties. These words are called hedges in fuzzy math circles. With fuzzy numbers, we can make approximate comparisons. It is quite possible, for example, to ask if an input person's age is approximately equal to about 30. This is often very useful when our data or imprecise, or when we don't want the rigidity of accepting a person 30 years old but rejecting one thirty years plus one day old. A very convenient way to describe fuzzy numbers is to use modifying words. For example, the fuzzy two shown in Figure 2 could be completely specified by "roughly 2". Other modifying words available are "nearly", "about" and crudely, with progressively larger uncertainties. These words are called hedges in fuzzy math circles. With fuzzy numbers, we can make approximate comparisons. It is quite possible, for example, to ask if an input person's age is approximately equal to about 30. This is often very useful when our data or imprecise, or when we don't want the rigidity of accepting a person 30 years old but rejecting one thirty years plus one day old.
Here is the answer. You can use it like this.
String strSQL="select * from player_Master where player_Id={0}";
IEnumerable<Player_Master> PlayerList = context11.ExecuteQuery<Player_Master>(strSQL, "10023");
Player_Master Paly11 = PlayertList.Single<Player_Master>();
Response.Write(Play11.PlayerName);
This is just a simpel
1. Web services can only be accessed over HTTP whereas .NET Remoting can be accessed over various protocols like TCP, HTTP etc.
2. Web services operate in a stateless environment since its HTTP, a stateless protocol whereas .NET remoting support state management (as in through Singleton and SingleCall objects)
3. Web services are more reliable than .NET Remoting.
4. Web services are easy to create and use while .NET Remoting are complex to be created.
5. Web services support heterogeneous environments i.e. support interoperability across platforms, on the other hand .NET remoting requires client to be built using .NET, thus it does'nt support heterogeneous environment.
6. Web Services support datatypes defined in the XSD type system while .NET remoting provides support for rich type system using binary communication.
This question was asked me in an interview.
What Is .NET Remoting?
As you may already know that application domains and processes are two mechanisms for isolation between applications. Processes are the main insulator between two different applications. Application domains is another extra isolation layer between different applications, but its main purpose is to isolate parts of code inside the same application. These parts will have the same isolation and restrictions as if they are different applications.
Now, what if for one reason or another we need to use a part of code located at different application domain running within the same application, located in different process running on the same machine, or located inside another process running on a different machine?. For uses like this, .Net remoting does exists.
Microsoft .Net Remoting is created to solve these problems. It provides a solution for communication between application domains and processes in a seamlessly and transparent way. This is due to the power of .Net remoting programming model and run time support.
When Microsoft developers designed .Net remoting framework, they have taken into consideration flexibility and customizability. This is done by separating the remotable object - in other words the object that you need to call remotely (located at another application domain or process) - from the client or server application domain and from any specific mechanism of communication. You can replace one communication protocol with a different one without the need to recompile the client or the server. Another flexibility related feature is that .Net remoting is a language independent framework, you can choose any application mode to communicate from. You can communicate using a web application, a console application, or a Windows Service. Any application can host a remoting object and provides its services to any client whether or not it is located within the same process boundaries, or in separate processes located on one machine or a set if disparate machines.
It is worth mentioning that objects in different application domains communicate using one of two techniques or methods. The first one is by transporting copies of objects across application domain boundaries. The second one is by using a proxy to exchange messages between them. .Net remoting framework uses the second technique.
.Net Remoting components
To allow an application located in different application domain or process to communicate with another one using .Net remoting technique, you have to just build the following:
Types of Remotable Objects
There are 3 types of remotable objects that you can configure and choose from depending on the requirements of your application.
How Does .NET Remoting Works?
As we mentioned previously you need to build a remotable type or object, a host or server application, and a client application to be able to communicate. In the client application you need only to create a new instance of the remotable object by using "New" or the instance creation function. When you do this the remoting system creates a proxy object that looks like the remote type to the client. When the client calls a method of the remotable type it actually call the method on the created proxy. The remoting system receives that call and routes it to the server process, it then processes the request, and returns the result to the client proxy, which in turn returns it to the client application. The client application will get the feeling of the remotable object as it is running inside the same process not inside another one. The proxy object is the system component that creates the impression that the server object is in the client's process not in a separate process or computer.
To get the above scenario to work perfectly, you actually need to know about two things: the first is channels, and the second is configuration.
Channels
If you try to build the remoting system yourself, you will need to learn network programming and a wide array of protocols and serialization formats. For purposes like that .NET remoting provides the concept of transport channel that represents the combination of the underlying technologies required to open a network connection and to use a particular protocol to send the bytes to the receiving application.
Channels are the transport media used to send / receive messages between applications across remoting boundaries (these boundaries can be between application domains, processes, or computers). A channel is an object that takes a stream of data, packages it according to a specific network protocol, and then sends the package to the other side. Channels can be categorized as channels which can send messages, channels which can receive messages, or channels which can perform both sending and receiving like the two .NET channels "HTTPChannel" and "TCPChannel".
By using the channel concept or technique you can plug in a wide range of protocols even if the common language runtime is not at the other end of the channel. You can also create your own channel object using whatever network protocol you prefer if it is not supported by the .NET framework.
You have to register at least one channel to use with the remoting infrastructure before being able to call the remotable type from the client application. You can register a channel in one of two ways: by calling "ChannelServices.RegisterChannel ", or by using a configuration file. You have to choose a specific port for your channel to listen on. If you are not sure whether a port is available or not, use 0 (zero) when you configuring your channel's port and the remoting system will choose an available port for you.
Configuration
The .NET remoting infrastructure needs specific information to work successfully and smoothly. That information is what we call configurations. You can choose one of the available two ways to configure your remotable types depending on your own preferences. The first way is by calling configuration methods directly from your server and client code, and this is what we call programmatic configuration. The second way is by creating an XML configuration file (.config file). To configure your remotable type properly whether by programmatic configuration or through a configuration file you have to provide the following information:
You should now recall that a .Net remoting application consists of three components. These are the remotable type, the host or server, and the client. In this part of our tutorial we will build a .NET remoting application using a technique nearly suitable for any scenario you may need to use .NET remoting with.
Building a .Net Remoting Application
.NET remoting has a very straightforward technique. If you want to build an application that uses .Net remoting to communicate across application domain boundaries all what you have to do is to implement the three components mentioned above. You also need to configure the remoting system to use remote activation for the remotable type. This requirements applies whatever the complexity of your remoting scenario.
Building a Remotable Type
The remotable object is a very typical / standard object, the difference is just it is being called from outside its application domain. To give any object the ability to be called from outside its application domain boundaries, the class that declare that object must inherit from "MarshalByRefObject" class. The "MarshalByRefObject" class is the base class for objects being communicated across application domains boundaries by exchanging messages using a proxy. So, when our class inherits this class, it automatically gets the same ability of communication as the "MarshalByRefObject" class. Also, the remotable class must be compiled into a .DLL library to be able to call its services. The following lines of code shows you an example of how to code a remotable type. First, open up your MS Visual Studio .NET, create new project, then add a new class to the created project. As shown in our example below the class name is "TheRemotableObject".
Public Class TheRemotableObject
Inherits MarshalByRefObject
Private List As String() = {"String1", "String2", "String3"}
Public Function ViewItem(ByVal ItemNum As Integer) As String
If ItemNum > List.GetUpperBound(0) _
Or ItemNum < List.GetLowerBound(0) Then Return "Error"
Return List(ItemNum)
End Function
End Class
The class shown in the above piece of code is a remotable class because it inherits the "MarshalByRefObject". It has a private list of strings and one public method or service. The method's mission is to take an integer list index as an input parameter, checks that the input is within the list boundaries and if so returns the specified or selected string to the caller.
Save the file containing the above created class - in our case it will be saved as "TheRemotableObject.vb". To compile this class into a library, use your command line tools shipped with the .NET framework SDK as shown in the following command line.
Note that: you should first run the [ Start / Programs / Microsoft Visual Studio 2005 / Visual Studio Tools / Visual Studio 2005 Command Prompt ] to be able to use the "vbc" compiler. You also have to run the following command from inside the directory inside which you saved the class file.
> vbc /t:library TheRemotableObject.vb
As a result of running the above command a new file "TheRemotableObject.dll" is now created at the same location as the "TheRemotableObject.vb" file.
Building a Host Application
Building such a remotable object as shown in the pervious section is not enough to make the required communication across application domains boundaries. Indeed, you need to build another kind of application to perform the communication process. You can think of building such a remotable type or object as just remarking this object as "could be shared or called remotely" but no more. You stilll need some kind of application being able of receiving calls to this newly created remotable object, identifying these calls, creating an instance from the called object, running the required service or method, and finally returning results to the caller. This is the host / server / listener application. A host application does its job by the mean of using channels. Channels are objects responsible of handling the network protocols and serialization formats on your behalf. In addition, the host application registers your remotable type with the .NET remoting system so that it can use your channel to listen for requests for your object. Host applications can be of any type. It can be a Windows forms application, an ASP.NET application, a Windows service application, a console application, or any type of a managed application.
Now, to an example:
Close all open projects or solutions, and create a new console application in a new directory (in our example we will name it example2). As a console application you will find module that is created by default (Module). Rename "Module1" as "Listener". Double click the "Listener" icon and change the module name shown in the code window. Add the imports statement and the lines of code inside the "Main" sub as shown in the following code snippet:
Imports System.Runtime.Remoting
Module Listener
Sub Main()
RemotingConfiguration.Configure("Listener.exe.config")
System.Console.WriteLine("Listener: Press <Enter> to exit ...")
System.Console.ReadLine()
End Sub
End Module
In the above code we firstly configure the remoting infrastructure by using a configuration file named "Listener.exe.config". Then we send a message to the user, and waiting till the user hits the <enter> key to exit. The last line main and only purpose is to keep the application running till the <enter> key is pressed.
The configuration file is an XML file specifying some configurations like the name and the URI of the remotable type, the kind of the used channel (whether it is an http or tcp channel), the port number to listen on, and the server activation mode. The remoting system uses the information in this file to listen for remote requests and route them to an instance of the remotable object or type. Below is a copy of the listener configuration file.
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
mode="Singleton"
type="TheRemotableObject, RemotableType"
objectUri="TheRemotableObject.rem"
/>
</service>
<channels>
<channel ref="http" port="8989"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
To compile the above "Listener.vb" module we will use the command line tools like in compiling the remotable object class above. Before compilation you have to save a copy of the "The remotableObject.dll" created in the previous example in the same directory with the "Listener.vb". Then save the above configuration file under the name specified in the listener module code file (which is "Listener.exe.config") in the same directory as the "Listener.vb" file. Position your command line prompt at the directory that contains the three files mentioned above then run the following command line.
> vbc /r:TheRemotableObject.dll Listener.vb
As a result you will get "Listener.exe" file in the same directory with the "Listener.vb".
Building a Client Application
To build a client application that utilizes the remotable type "TheRemotableObject" and hosted by the "Listener" application created above, you have to register this client application as a client for the specified remotable type. When you do this, the client application will call the remotable type as if it does exist in the same application domain with the client. The following code example shows you how to build a client application.
Close all open projects and solution in your Visual Studio .NET 2005 then create a new console application giving it a name and a directory to be created in (in our example the project name will be "Example3"). Rename the default created module "Module1" to "Client" then double click its icon to open the code file. Rename the module to "Client". Add the imports statement and the lines of code inside the "Main" sub as shown in the following code snippet.
Imports System.Runtime.Remoting
Module Client
Sub Main()
RemotingConfiguration.Configure("Client.exe.config")
Dim RM As New TheRemotableObject()
System.Console.WriteLine("Result = " + RM.ViewItem(1))
End Sub
End Module
As shown in the code above you have to configure the remoting infrastructure with the "Client.exe.config" XML configuration file. Then you define and create a new instance of the remotable type "TheRemotableObject". Call the remotable method "ViewItem" then write the result to the console. Although the "TheRemotableObject" type is not in the same application domain with the "Client" but you will be able to call its services "ViewItem" remotly and will be able to receive the results. Of course the last two lines of code in the "Main" subroutine will be marked as error but this is not a matter, just ignore it.
Write the following configuration file and save it under the name "Client.exe.config" at the same directory of the "Client.vb" code file.
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown
type="TheRemotableObject, RemotableType"
Url="http://localhost:8989/TheRemotableObject.rem"
/>
</client>
</application>
</system.runtime.remoting>
</configuration>
The configuration file tells the remoting system that the type information of the remotable type can be found in the "TheRemotableType" assembly. This remotable object located at "http://localhost:8989/TheRemotableObject.rem". If you want to run this application over a network, you have to write the remote computer name instead of "localhost" in the url above. You must pay attention when you write a configuration file. Although it is simple but most errors comes from incorrect settings or mismatching between settings in the two configuration files used by client and host applications.
Now put a copy of the "TheRemotableObject.dll" created in example1 and compile the above "Client.vb" using command line tools as follows.
> vbc /r:TheRemotableObject.dll Client.vb
As a result you will get "Client.exe" file at the same directory with the "Client.vb".
Running The Complete .NET Remoting application
Now The situation is : We have one directory called "Example2" (which is the listener directory) that contains "Listener.exe", "Listener.exe.config", and "TheRemotableObject.dll" files. We have another directory called "Example3" (which is the client directory) that contains "Client.exe", "Client.exe.config", and "TheRemotableObject.dll" files. Note: "Example2", and "Example3" are depicted as "L" and "cl" in the figure below.
Figure 1 - The host listing to the client and fulfill its requests
To run and test the remoting process between these two different applications where each one of them has its own application domain and process boundaries do the following: Run the command line prompt at the listener directory and type: Listener, then press <enter>. A message will be displayed as shown in figure1 in the above window. Now open a new command prompt in the client directory and type: Client, then press <enter>. When you do so the client application will call the remotable type, while the server at the other side of the channel listening for any requests. It receives the client request, process it then returns the results back to the client. The client gets the result and displays it to you at the client command prompt as shown in figure1 in the second window.
Links Related to INDIA
Some Good Views About Life
Some Good Posters
India Today
India World
Indolink
The Times of India
Gujarat Samachar : Sandesh
Weather - India
Listern to GARBA Audio
Links related to India
Consulate General of India
Other Useful Links
CNN News
BBC News
Good Magazines, TIME, People,...
Good Search Engines
Links to Astronomy
INS Home Page
VISA Informations
National Park Service
California Travel & Tourism
Bay Area Favorites
Silicon Valley Gateway
Virtual Job Search
The Right Place for Job Hunting
Career Mosaic
General Aid
Integrated System Design
Microprocessor Design Resource
EE Times
UNIX Reference Desk
Another UNIX Reference Desk
Mirco Times
Dictonary of Computing Contents
Library Online/Quick Reference
Missile Cammando - Game
NASA Web Page
Shuttle/MIR Web Page
NSSDC Photo Gallery
HST Picture Gallery
Big Bear Solar Observatory
SEDS:Good Astro Search Engine
Apollo Lunar Surface Journal
Top 10 Business Movies according to Inc.com. Interestingly, most of them show businessmen as greedy bad guys.
This article covers using application configuration files in Microsoft .NET. It briefly outlines the concept of application configuration files In particular, it discusses using the System.Configuration namespace
Application Configuration Background
Building configurable applications is not a new concept. The idea of applications relying on configuration parameters to dictate behavior at run time has been around for many years. For those of us who were around Microsoft-based programming prior to .NET, the most common example is the use of INI files. INI files are simple text-based files with key and value pairs; the key is used to fetch the value, and the value is then used in some way to influence the application settings and/or resulting behavior. This way, you can modify the configuration file to drive program behavior without having to recompile the application.
INI files generally worked great, except for the following drawbacks:
Microsoft moved away from INI files and towards storing everything in the Registry, which made application deployment much more difficult. As a result, Microsoft moved back to the concept of an "xcopy deployment," by which programmers deployed applications by simply copying files. Redmond used XML and some objects built into the Microsoft .NET Framework to bring new life to our old friend the application configuration file.
System.Configuration Basics
The System.Configuration namespace provides the functionality for reading configuration files. Microsoft released an XML schema dictating the format for configuration files that can be read using the System.Configuration API, enabling the accessing object to automatically consume the configuration files. This way, you can allow configuration files to be read without having to develop
The name and storage location of an application configuration file depends on the application type with which it is being used. A configuration file for an executable (.exe) is located in the same directory as the application. The file is the name of the application with a .config extension. For example, notepad.exe would have a configuration file of notepad.exe.config. A configuration file for an ASP.NET application is called web.config and is located in the root of the application's virtual directory.
appSettings Section
An application configuration file follows a specific XML schema. The appSettings section is a predefined section of the configuration file designed to make it very easy to retrieve a value based on a given name. This is the easiest way to add application-specific settings into an application configuration file. The appSettings section of the configuration file consists of a series of "add" elements with "key" and "value" attributes. While the appSettings section is predefined, it is not included in a configuration file by default and must be manually added. A simple example of a configuration file would be the following:
<?xml version="1.0"
encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ApplicationTitle"
value="Sample Console Application" />
<add key="ConnectionString"
value="Server=localhost;Database=Northwind;Integrated
Security=false;User Id=sa;Password=;" />
</appSettings>
</configuration>
The AppSettings property of the ConfigurationSettings object in the System.Configuration namespace is used to get the settings. For example, to read either of the settings above, the following sample code would do the trick:
// Read appSettings
string title = ConfigurationSettings.AppSettings["ApplicationTitle"];
string connectString =
ConfigurationSettings.AppSettings["ConnectionString"];
Now, you could easily set a dynamic title value or read database connection string information from the application configuration file. This gives you the freedom to adjust settings without having to recompile any code.
Customized Configuration Sections
If you have distinct groupings of configurations to be included in the application configuration file, consider creating a custom configuration section in lieu of the appSettings section. This will allow you more organizational structuring around the storage of various settings. You include a custom section by including the configSections element in the configuration file and a sub-element called section that defines the custom section and the handler for reading it. The .NET Framework contains an IConfigurationSectionHandler interface that dictates the required functionality handlers provide by allowing you to use custom handlers with the Configuration if you so choose. This example just uses handlers the .NET Framework already provides. Continuing the example from the previous section, the following configuration file contains a custom section and specifies which handler to use for reading:
<?xml version="1.0"
encoding="utf-8" ?>
<configuration>
<configSections>
<section name="sampleSection"
type="System.Configuration.SingleTagSectionHandler" />
</configSections>
<sampleSection ApplicationTitle="Sample Console Application"
ConnectionString="Server=localhost;Database=Northwind;
Integrated Security=false;User Id=sa;
Password=;" />
<appSettings>
<add key="ApplicationTitle"
value="Sample Console Application" />
<add key="ConnectionString"
value="Server=localhost;Database=Northwind;
Integrated Security=false;User Id=sa;Password=;" />
</appSettings>
</configuration>
The following code reads the configuration settings into a dictionary, where you can easily access the values:
// Read customSection
System.Collections.IDictionary sampleTable = (IDictionary)
ConfigurationSettings.GetConfig("sampleSection");
string title = (string)sampleTable["ApplicationTitle"];
string connectString = (string)sampleTable["ConnectionString"];
Customized Configuration Sections and Groups
The issue with custom configuration sections alone is that they rely on attributes to store all of the settings as a part of a single element. This can become cumbersome when a large number of configurations are contained within a section or additional related sections. You can further organize similar custom sections into a section group, which makes it easier to work with numerous configurations and helps eliminate naming conflicts with custom configuration sections. This is especially useful where your application contains reference to several other DLLs that read configuration information from the host applications configuration file. A sectionGroup element is simply placed around one or more section elements to create a group. Expanding the example configuration file, the following configuration file contains a custom group, section, and the pre-defined appSettings:
<?xml version="1.0"
encoding="utf-8" ?>
<configuration>
<configSections>
<section name="sampleSection"
type="System.Configuration.SingleTagSectionHandler" />
<sectionGroup name="CodeGuru">
<section name="utilitySection"
type="System.Configuration.NameValueSectionHandler,
System,Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
</sectionGroup>
</configSections>
<sampleSection ApplicationTitle="Sample Console Application"
ConnectionString="Server=localhost;Database=Northwind;
Integrated Security=false;User Id=sa;
Password=;" />
<CodeGuru>
<utilitySection>
<add key="ApplicationTitle"
value="Sample Console Application" />
<add key="ConnectionString"
value="Server=localhost;Database=Northwind;
Integrated Security=false;User Id=sa;
Password=;" />
</utilitySection>
</CodeGuru>
<appSettings>
<add key="ApplicationTitle"
value="Sample Console Application" />
<add key="ConnectionString"
value="Server=localhost;Database=Northwind;
Integrated Security=false;User Id=sa;Password=;" />
</appSettings>
</configuration>
Note the extra "Version," "Culture," and "PublicKeyToken" specified in defining a section group. These all come from what the machine.config configures on the local machine. Occasionally, it has worked for me without them, but other times an exception is thrown that it can't create the appropriate handler. I've found that if I include those items, it consistently works.
The following code can access the items in the custom group by loading the group into a NameValueCollection for easy access to the key and value pairs:
// Read custom sectionGroup
NameValueCollection collection = (NameValueCollection)
ConfigurationSettings.GetConfig("CodeGuru/utilitySection");
string title = collection["ApplicationTitle"];
string connectString = collection["ConnectionString"];
Note the path-like statement required to find the appropriate section to read when accessing the custom section.
Possible Enhancements
This article has touched on some of the basics of using application configuration files, including the ability to define your own sections and groups of sections. Here are a couple of additional items for you to ponder about application configuration settings:
SDLC
|
The software development life cycle (SDLC) is the entire process of formal, logical steps taken to develop a software product. The phases of SDLC can vary somewhat but generally include the following:
Requirements Analysis
Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements.
Specification
Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.
Software architecture
The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.
Coding
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.
Testing
Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer.
Documentation
An important task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces.
Software Training and Support
A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are occasionally resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, its very important to have training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software. Users will have lots of questions and software problems which leads to the next phase of Software.
Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About 2/3 of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs.
Process Models
There are several methodologies or models that can be used to guide the software development lifecycle. Some of these include:
--Linear or Waterfall Model
--Rapid Application Development (RAD)
--Joint Application Development (JAD)
--Prototyping Model
--Fountain Model
--Spiral Model
--Build and Fix
--Synchronize-and-Stabilize
Rapid Application Development
"Rapid Application Development (RAD) is an incremental software development process model that emphasizes a very short development cycle typically 60-90 days". The RAD approach encompasses the following phases:
1.Business Modeling
2.Data Modeling
3.Process Modeling
4.Application Generation
5.Testing and Turnover
Business Modeling
The information flow among business functions is modeled in am way that answers the following questions:
1.What information drives the business process?
2.What information is generated?
3.Who generates it?
4.Where does the information go?
5.Who processes it?
Data Modelling
The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristic of each object is identified and the relationship between these objects are defined.
Process Modelling
The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing the descriptions are created for adding, modifying, deleting or retrieving data object.
Application Generation
RAD assumes the use of the RAD tools like VB,VC++,Delphi etc rather than creating
software using conventional third generation programming languages. The RAD works to reuse
existing program components or create reusable components. In all cases, automated tools are used to facilitate construction of the software.
Testing and Turnover
Since the RAD process emphasizes reuse, many of the program components have already been tested. This minimize the testing and development time.
DFD Data Flow Diagrams A data flow diagram is a graphical technique that depicts information flow and the transforms that are applied as data move from input to output. The data flow diagram is also known as 'data flow graph'. Various symbols are used to depict the data from one level to another level. |
Notation
Logical data flow diagrams can be completed using only four simple notations, i.e. special symbols or icons and the annotation that associates them with a specific system the Yourdon approach is used.
1.DataFlow
Data move in a specific direction from an origin to a destination in the form of a document. The data flow is a "packet of data".
2.Process
People procedure or devices that use or produce data. The physical component is not identified.
3.Source or Destination
External sources or destinations of data interact with the system but are outside its boundary.
4.Data Store
Here data are stored or referenced by process in the system.
1. Introduction
|
1.3 Overview
Provides a brief overview of the product defined as a result of the requirements elicitation process.
1.4 Business Context
Provides an overview of the business organization sponsoring the development of this product. This overview should include the business's mission statement and its organizational objectives or goals.
2.1 Product Functions
Describes the general functionality of the product, which will be discussed in more detail below.
2.2 Similar System Information
Describes the relationship of this product with any other products. Specifies if this product is intended to be stand-alone, or else used as a component of a larger product. If the latter, this section discusses the relationship of this product to the larger product.
2.3 User Characteristics
Describes the features of the user community, including their expected expertise with software systems and the application domain.
2.4 User Problem Statement
This section describes the essential problem(s) currently confronted by the user community.
2.5 User Objectives
This section describes the set of objectives and requirements for the system from the user's perspective. It may include a "wish list" of desirable characteristics, along with more feasible solutions that are in line with the business objectives.
2.6 General Constraints
Lists general constraints placed upon the design team, including speed requirements, industry protocols, hardware platforms, and so forth.
This section lists the functional requirements in ranked order. Functional requirements describes the possible effects of a software system, in other words, what the system must accomplish. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe how the system accomplishes its functional requirements. Each functional requirement should be specified in a format similar to the following:
- Short, imperative sentence stating highest ranked functional requirement.
Description
A full description of the requirement.
Criticality
Describes how essential this requirement is to the overall system.
Technical issues
Describes any design or implementation issues involved in satisfying this requirement.
Cost and schedule
Describes the relative or absolute costs associated with this issue.
Risks
Describes the circumstances under which this requirement might not able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.
Dependencies with other requirements
Describes interactions with other requirements.
... others as appropriate
b) <Name of second highest ranked requirement>
And so forth...
This section describes how the software interfaces with other software products or users for input or output. Examples of such interfaces include library routines, token streams, shared memory, data streams, and so forth.
4.1 User Interfaces
Describes how this product interfaces with the user.
4.1.1 GUI
Describes the graphical user interface if present. This section should include a set of screen dumps or mockups to illustrate user interface features.
If the system is menu-driven, a description of all menus and their components should be provided.
4.1.2 CLI
Describes the command-line interface if present. For each command, a description of all arguments and example values and invocations should be provided.
4.1.3 API
Describes the application programming interface, if present. For each public interface function, the name, arguments, return values, examples of invocation, and interactions with other functions should be provided.
4.1.4 Diagnostics or ROM
Describes how to obtain debugging information or other diagnostic data.
4.2 Hardware Interfaces
Describes interfaces to hardware devices.
4.3 Communications Interfaces
Describes network interfaces.
4.4 Software Interfaces
Describes any remaining software interfaces not included above.
Specifies speed and memory requirements.
Specifies any constraints for the design team using this document.
6.1 Standards Compliance
6.2 Hardware Limitations
... others as appropriate
Specifies any other particular non-functional attributes required by the system. Examples are provided below.
7.1 Security
7.2 Binary Compatibility
7.3 Reliability
7.4 Maintainability
7.5 Portability
7.6 Extensibility
7.7 Reusability
7.8 Application Affinity/Compatibility
7.9 Resource Utilization
7.10 Serviceability
... others as appropriate
This section presents a list of the fundamental objects that must be modelled within the system to satisfy its requirements. The purpose is to provide an alternative, "structural" view on the requirements stated above and how they might be satisfied in the system.
8.1 Inheritance Relationships
This section should contain a set of graphs that illustrate the primary inheritance hierarchy (is-kind-of) for the system.
8.2 Class descriptions
This section presents a more detailed description of each class identified during the OO Domain Analysis.
Each class description should conform to the following structure:
8.2.1 <Class name>
8.2.1.1 Abstract or Concrete:
Indicates whether this class is abstract or concrete.
8.2.1.2 List of Superclasses:
Names all immediate superclasses.
8.2.1.3 List of Subclasses:
Names all immediate subclasses.
8.2.1.4 Purpose:
States the basic purpose of the class.
8.2.1.5 Collaborations:
Names each class with which this class must interact in order to accomplish its purpose, and how.
8.2.1.6 Attributes:
Lists each attribute (state variable) associated with each instance of this class, and indicates examples of possible values (or a range).
8.2.1.7 Operations:
Lists each operation that can be invoked upon instances of this class. For each operation, the arguments (and their type), the return value (and its type), and any side effects of the operation should be specified.
8.2.1.8 Constraints:
Lists any restrictions upon the general state or behavior of instances of this class.
This section should describe a set of scenarios that illustrate, from the user's perspective, what will be experienced when utilizing the system under various situations.
In the article Inquiry-Based Requirements Analysis (IEEE Software, March 1994), scenarios are defined as follows:
In the broad sense, a scenario is simply a proposed specific use of the system. More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use case, which consists merely of a short description with a number attached. More detailed forms are called scripts. These are usually represented as tables or diagrams and involved identifying an action and the agent (doer) of the action. FOr this reason, a script can also be called an action table.
Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because the describe the system's behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.
This section provides an initial version of the project plan, including the major tasks to be accomplished, their interdependencies, and their tentative start/stop dates. The plan also includes information on hardware, software, and wetware resource requirements.
The project plan should be accompanied by one or more PERT or GANTT charts.
This section provides an initial budget for the project, itemized by cost factor.
Specifies other useful information for understanding the requirements. All SRS documents should include at least the following two appendices:
12.1 Definitions, Acronyms, Abbreviations
Provides definitions of unfamiliar definitions, terms, and acronyms.
12.2 References
Provides complete citations to all documents and meetings referenced or used in the preparation of this document.
