Online Art Gallery

CONTENTS
1. INTRODUCTION
2. DESIGN PRINCIPLES & EXPLANATION
2.1. MODULES
3.2. MODULE DESCRIPTIOIN
4. PROECT DICTIONAR!
4.1. DATA"LO# DIAGRAMS
4.2. E$R DIAGRAMS
4.3. DATA DICTIONAR!
%. "ORMS & REPORTS
%.1. I&O SAMPLES
'. (I(ILIOGRAP)!
1. INTRODUCTION
Online Art Gallery is an online application, which is used to
display and sell art works of artist irrespective of their nationality,
gender and other narrow consideration, through auction. Artist can
register online for being a member in the art gallery and each artist
can upload the digital copy of their art work under the respective
categories. They can host their art work either for auction or for
fixed price. The artist is liable to pay a fraction of the price of each
art work to the web site to find the running fund for site. Art lovers
have to go to the art exhibition to collect their favorite arts or
painting. But now-a-days they are not getting enough time to go to
the galleries and collect the arts and paintings.
Existing System:
ustomer can also register online and they can browse art
works that are arranged in different categories scientifically. !ach
ustomer can create their own gallery to see his favorite art works
with out much difficult. And each user has the right to purchase an
art work using the integrated payment gateway and participate in
auction by submitting their bids. "ualified bidder should remit the
amount using payment gateway and after each valid payment the
art work will be shipped within some days.
Proposed System#
O$%&$! A'T (A%%!') is a application software and it is very
helpful for the art lovers and others who wants to know the
addresses where this kind of arts will we sold.

This application helps the end-users to search their arts and
paintings and they can place order for the selected pieces. The end-
user can also get the information about the art exhibition and the
respective address, so, that they can visit to those exhibitions.
Art (allery brings you an opportunity to view online art
exhibitions at our Online Art (allery we bring you details of all
art exhibitions held in the past and the forthcoming show. The
Online Art (allery is updated daily, so the user can view and buy
the latest collection of contemporary art online from any where in
the world. )ou can view and buy the latest &ndian contemporary
art collection available at their exhibitions and also at their online
gallery.
An
2. DESIGN PRINCIPLES & EXPLANATION
2.1. MODULES
*ser 'egistration
Art !xhibition
Artist +irectory
ontact *s
Th
4. PROECT DICTIONAR!
4.1. DATA"LO# DIAGRAMS
Data *l+, -ia.ra/ i0 10e- t+ -e2rea0e analy0i0 t3e /+4e/ent +*
-ata t3r+1.3 a 0y0te/ 0t+re +* -ata in t3e 0y0te/. Data *l+, -ia.ra/0
are t3e 2entral t++l 5a0in. +n ,3i23 2+/6+nent0 are -e4el+6e-.
T3e tran0*+r/ati+n +* -ata *r+/ in61t t+ +1t61t7 t3r+1.3 6r+2e00
/ay 5e -e02ri5e l+.i2ally an- in-e6en-ently +* 63y0i2ally 2+/6+nent0
a00+2iate- ,it3 t3e 0y0te/. T3ey are 2alle- l+.i2al -ata *l+, -ia.ra/0.
In 2+ntra0t 63y0i2al -ata *l+, -ia.ra/0 03+, t3e a2t1al
i/6le/entati+n an- /+4e/ent +* -ata 5et,een 6e+6le7 De6art/ent7
an- ,+r8 0tati+n.
T3e -ata *l+, -ia.ra/ 03+, *1n2ti+nal 2+/6+0iti+n +* t3e
0y0te/. T3e *ir0t le4el +* 2+n2e6t1al le4el in 2+nte9t -ia.ra/ i0 *l+,e-
5y t3e -e02ri6ti+n +* in61t an- +1t61t *+r ea23 +* entitie0 t3e ne9t
le4el +* -*- i0 le4el :7 ,3i23 03+,0 t3e /ain *1n2ti+n0 in t3e 0y0te/.
Le4el : i0 *+ll+,e- 5y t3e -e02ri6ti+n +* t3e /ain *1n2ti+n0. T3e /ain
*1n2ti+n *1rt3er 5r+8en int+ *1n2ti+n0 an- 015 *1n2ti+n0.
,.-. +.+ +iagrams#
+.+ level /#
ART
GALLERY
MEMBERB
ARTIST
ADMIN
DFD level 1 member:
MEMBER
REGEST
ATION
LOG
IN
CHANGE
PASS
WORD
GET
PROFILE
VIEW
ART
GALLE
RY
SEARC
H
ARTIST
WISE
ADD
CART
SELEC
T ART
BILLI
NG &
SHIP
PING
ORD
ER
NOW
PAY
MEN
T
CON
FIRM
ATIO
N
DATA BASE
DFD Level 1 Artist:
ARTIST
REGES
TRATIO
N
CHANG
EPASS
WORD
DATA BASE
LOGIN
GET
PROFI
LE
VEW
GALLE
RY
SEARCH
BY
ARTIST
UPLOA
D ART
DFD Level 1 Admin:
MEMBER
ART
GALLERY
ARTIST
ADMIN
DATA
BASE
Context Diagram:
MEMBER
ART
GALLERY
ARTIST
ADMIN
login
regiser
Ge !e"ils
login
regiser
Ge !e"ils
r"ns"#ions
A#i$"e &
!e"#i$"ion
,.0. !-' +iagrams#
Authentication
1ember Artist
$o yes
1ember
%ogin Artist
*plo
ad
profile
2iew
Billing
Order
artby
Arts
pwd uid
unam
e
pwd
!mail
*nam
e
.nam
e
Artist
Artpat
h
Artid
3hipping
gg
Artist
Artpat
h
artid
4ayment
+rafts
redit
ity
uname
pwd
Ob5ect diagram#
A%A!&in
M%Me&'er
L%Login R%Regiser
T%Tr"ns"#ions
G%G"ller(
)%)
)%)
)%)
)%)
)%)
)%*
)%*
)%*
)%*
Activity diagram for 1ember#
Regisr"ion
In+, !e"ils
Sore !e"ils
Dis+l"( !e"ils
V"li!
Login
Ge +ro-ile
Vie. g"ller(
A!! o #"r
+"ss.or!
P"(&en
Yes
No
Activity diagram for Artist#
Regisr"ion
In+, !e"ils
Sore !e"ils
Dis+l"( !e"ils
V"li!
Login
Ge +ro-ile
Vie. g"ller(
U+!"e G"ller(
Yes
No
3tate hat diagrams#
3tate chart +iagram for Online registration#
MEMBER REGISTRATION ADMIN DATA BASE
REGISTRATION
VALIDATION
STORE
CONFORMATION
3tate chart +iagram for Online Transactions#
MEMBER LOGIN
ADMIN
TRANSACTIONS DATABASE
login $"li!
+,r#/"se
sore
#on-or&"ion
Uml diagrams:
For member:
Use case diagram:
member
Registration
Artist
Login
getprofile
ViewGallery
SearchbyArtist
Addtocart
Shippingdetails
payment
Admin
Class Diagram:
view gallery
artid
artist
art path
art cost
get arts()
billing
shipping
name2
submit()
order
artid
artistname
artpath
artcost
order()
member
uid type ! int
uname type ! char
email
fname type ! int
lname type ! int
city type ! varchar
pwd
register()
1:*
1:*
1:*
payment
drafts
credit
debit
payment()
1:*
get profile
fname type ! char
lname type ! initval
gender type ! char
email
city type ! char
update()
1:*
Admin
userid type ! varchar
pwd type ! varchar
Activate()
deactivate()
"ransactions()
deliverSoldArts()
1:1
1:1
1:1
1:1
1:1
1:1
login
uname type ! char
pwd
login()
1:*
1:1
Collaboration:
member
login
get
profile
view
gallery
billing
order

payment
Admin
member
2 login( )
# update( )
$ get arts( )
% submit( )
& order( )
' payment( )
( "ransactions
) *onfirmations
+ register( )
Seqence diagram:
member login get profile view gallery billing order payment
Admin
member
2 login( )
# update( )
$ get arts( )
% submit( )
& order( )
' payment( )
+ register( )
( "ransactions
) *onfirmations
.or artist#
lass diagram#
view gallery
artid
artist
art path
art cost
get arts()
get profile
fname type ! char
lname type ! initval
gender type ! char
email
city type ! char
update()
login
uname type ! char
pwd
login()
Admin
userid type ! varchar
pwd type ! varchar
Activate()
deactivate()
"ransactions()
deliverSoldArts()
1:1
1:1
1:1
artist
uid type ! int
uname type ! char
email
fname type ! int
lname type ! int
city type ! varchar
pwd
register()
1:*
1:*
1:1
1:*
upload
artid
artist
art si,e
artpath
artcost
upload()
1:*
ollabora#
# update( )
artist
login
get
profile
upload
view
gallery
Artist
Admin
+ register( )
2 login( )
& chec- arts
' conformation
$ upload( )
% get arts( )
3e6uence#
login artist get profile upload view gallery
Artist
Admin
+ register( )
2 login( )
# update( )
$ upload( )
% get arts( )
& chec- arts
' conformation
Mi2r+0+*t.NET "ra/e,+r8
The .$!T .ramework is a new computing platform that simplifies
application development in the highly distributed environment of the
&nternet. The .$!T .ramework is designed to fulfill the following
ob5ectives#
To provide a consistent ob5ect-oriented programming environment
whether ob5ect code is stored and executed locally, executed locally
but &nternet-distributed, or executed remotely.
To provide a code-execution environment that minimi7es software
deployment and versioning conflicts.
To provide a code-execution environment that guarantees safe
execution of code, including code created by an unknown or semi-
trusted third party.
To provide a code-execution environment that eliminates the
performance problems of scripted or interpreted environments.
To make the developer experience consistent across widely varying
types of applications, such as 8indows-based applications and 8eb-
based applications.
To build all communication on industry standards to ensure that code
based on the .$!T .ramework can integrate with any other code.
The .$!T .ramework has two main components# the common language
runtime and the .$!T .ramework class library. The common language
runtime is the foundation of the .$!T .ramework. )ou can think of the
runtime as an agent that manages code at execution time, providing core
services such as memory management, thread management, and remoting,
while also enforcing strict type safety and other forms of code accuracy that
ensure security and robustness. &n fact, the concept of code management is a
fundamental principle of the runtime. ode that targets the runtime is known
as managed code, while code that does not target the runtime is known as
unmanaged code. The class library, the other main component of the .$!T
.ramework, is a comprehensive, ob5ect-oriented collection of reusable types
that you can use to develop applications ranging from traditional command-
line or graphical user interface 9(*&: applications to applications based on
the latest innovations provided by A34.$!T, such as 8eb .orms and ;1%
8eb services.
The .$!T .ramework can be hosted by unmanaged components that load
the common language runtime into their processes and initiate the execution
of managed code, thereby creating a software environment that can exploit
both managed and unmanaged features. The .$!T .ramework not only
provides several runtime hosts, but also supports the development of third-
party runtime hosts.
.or example, A34.$!T hosts the runtime to provide a scalable, server-side
environment for managed code. A34.$!T works directly with the runtime
to enable 8eb .orms applications and ;1% 8eb services, both of which
are discussed later in this topic.
&nternet !xplorer is an example of an unmanaged application that hosts the
runtime 9in the form of a 1&1! type extension:. *sing &nternet !xplorer to
host the runtime enables you to embed managed components or 8indows
.orms controls in <T1% documents. <osting the runtime in this way makes
managed mobile code 9similar to 1icrosoft= Active;= controls: possible,
but with significant improvements that only managed code can offer, such as
semi-trusted execution and secure isolated file storage.
The following illustration shows the relationship of the common language
runtime and the class library to your applications and to the overall system.
The illustration also shows how managed code operates within a larger
architecture.
Features of the Common Language Runtime
The common language runtime manages memory, thread execution, code
execution, code safety verification, compilation, and other system services.
These features are intrinsic to the managed code that runs on the common
language runtime.
8ith regards to security, managed components are awarded varying degrees
of trust, depending on a number of factors that include their origin 9such as
the &nternet, enterprise network, or local computer:. This means that a
managed component might or might not be able to perform file-access
operations, registry-access operations, or other sensitive functions, even if it
is being used in the same active application.
The runtime enforces code access security. .or example, users can trust that
an executable embedded in a 8eb page can play an animation on screen or
sing a song, but cannot access their personal data, file system, or network.
The security features of the runtime thus enable legitimate &nternet-deployed
software to be exceptionally feature rich.
The runtime also enforces code robustness by implementing a strict type-
and code-verification infrastructure called the common type system 9T3:.
The T3 ensures that all managed code is self-describing. The various
1icrosoft and third-party language compilers
(enerate managed code that conforms to the T3. This means that managed
code can consume other managed types and instances, while strictly
enforcing type fidelity and type safety.
&n addition, the managed environment of the runtime eliminates many
common software issues. .or example, the runtime automatically handles
ob5ect layout and manages references to ob5ects, releasing them when they
are no longer being used. This automatic memory management resolves the
two most common application errors, memory leaks and invalid memory
references.
The runtime also accelerates developer productivity. .or example,
programmers can write applications in their development language of
choice, yet take full advantage of the runtime, the class library, and
components written in other languages by other developers. Any compiler
vendor who chooses to target the runtime can do so. %anguage compilers
that target the .$!T .ramework make the features of the .$!T .ramework
available to existing code written in that language, greatly easing the
migration process for existing applications.
8hile the runtime is designed for the software of the future, it also supports
software of today and yesterday. &nteroperability between managed and
unmanaged code enables developers to continue to use necessary O1
components and +%%s.
The runtime is designed to enhance performance. Although the common
language runtime provides many standard runtime services, managed code is
never interpreted. A feature called 5ust-in-time 9>&T: compiling enables all
managed code to run in the native machine language of the system on which
it is executing. 1eanwhile, the memory manager removes the possibilities of
fragmented memory and increases memory locality-of-reference to further
increase performance.
.inally, the runtime can be hosted by high-performance, server-side
applications, such as 1icrosoft= 3"% 3erver? and &nternet &nformation
3ervices 9&&3:. This infrastructure enables you to use managed code to write
your business logic, while still en5oying the superior performance of the
industry@s best enterprise servers that support runtime hosting.
.NET Framework Class Library
The .$!T .ramework class library is a collection of reusable types that
tightly integrate with the common language runtime. The class library is
ob5ect oriented, providing types from which your own managed code can
derive functionality. This not only makes the .$!T .ramework types easy to
use, but also reduces the time associated with learning new
features of the .$!T .ramework. &n addition, third-party components can
integrate seamlessly with classes in the .$!T .ramework.
.or example, the .$!T .ramework collection classes implement a set of
interfaces that you can use to develop your own collection classes. )our
collection classes will blend seamlessly with the classes in the .$!T
.ramework.
As you would expect from an ob5ect-oriented class library, the .$!T
.ramework types enable you to accomplish a range of common
programming tasks, including tasks such as string management, data
collection, database connectivity, and file access. &n addition to these
common tasks, the class library includes types that support a variety of
speciali7ed development scenarios. .or example, you can use the .$!T
.ramework to develop the following types of applications and services#
onsole applications.
3cripted or hosted applications.
8indows (*& applications 98indows .orms:.
A34.$!T applications.
;1% 8eb services.
8indows services.
.or example, the 8indows .orms classes are a comprehensive set of
reusable types that vastly simplify 8indows (*& development. &f you write
an A34.$!T 8eb .orm application, you can use the 8eb .orms classes.
Client Application Deelopment
lient applications are the closest to a traditional style of application in
8indows-based programming. These are the types of applications that
display windows or forms on the desktop, enabling a user to perform a task.
lient applications include applications such as word processors and
spreadsheets, as well as custom business applications such as data-entry
tools, reporting tools, and so on. lient applications usually employ
windows, menus, buttons, and other (*& elements, and they likely access
local resources such as the file system and peripherals such as printers.
Another kind of client application is the traditional Active; control 9now
replaced by the managed 8indows .orms control: deployed over the
&nternet as a 8eb page. This application is much like other client
applications# it is executed natively, has access to local resources, and
includes graphical elements.
&n the past, developers created such applications using ABB in con5unction
with the 1icrosoft .oundation lasses 91.: or with a rapid application
development 9'A+: environment such as 1icrosoft= 2isual Basic=.
The .$!T .ramework incorporates aspects of these existing products into a
single, consistent development environment that drastically simplifies the
development of client applications.
The 8indows .orms classes contained in the .$!T .ramework are designed
to be used for (*& development. )ou can easily create command windows,
buttons, menus, toolbars, and other screen elements with the flexibility
necessary to accommodate shifting business needs.
.or example, the .$!T .ramework provides simple properties to ad5ust
visual attributes associated with forms. &n some cases the underlying
operating system does not support changing these attributes directly, and in
these cases the .$!T .ramework automatically recreates the forms. This is
one of many ways in which the .$!T .ramework integrates the developer
interface, making coding simpler and more consistent.
*nlike Active; controls, 8indows .orms controls have semi-trusted access
to a user@s computer. This means that binary or natively executing code can
access some of the resources on the user@s system 9such as (*& elements and
limited file access: without being able to access or compromise other
resources. Because of code access security, many applications that once
needed to be installed on a user@s system can now be safely deployed
through the 8eb. )our applications can implement the features of a local
application while being deployed like a 8eb page.
C!"#et $or %indo&s Application
Overview of the .$!T .ramework
The .$!T .ramework is a managed type-safe environment for application
development and execution. The .$!T .ramework manages all aspects of
your programCs execution. &t allocates memory for the storage of data and
instructions, grants or denies the appropriate permissions to your
application, initiates and manages application execution, and manages the
reallocation of memory from resources that are no longer needed. The .$!T
.ramework consists of two main components# the common language
runtime and the .$!T .ramework class library.
The common language runtime can be thought of as the environment that
manages code execution. &t provides core services, such as code compilation,
memory allocation, thread management, and garbage collection. Through the
common type system 9T3:, it enforces strict type-safety and ensures that
code is executed in a safe environment by also enforcing code access
security.
The .$!T .ramework class library provides a collection of useful and
reusable types that are designed to integrate with the common language
runtime. The types provided by the .$!T .ramework are ob5ect-oriented and
fully extensible, and they allow you to seamlessly integrate your
applications with the .$!T .ramework.
%anguages and the .$!T .ramework
The .$!T .ramework is designed for cross-language compatibility, which
means, simply, that .$!T components can interact with each other no matter
what supported language they were written in originally. 3o, an application
written in 1icrosoft 2isual Basic .$!T might reference a dynamic-link
library 9+%%: file written in 1icrosoft 2isual D, which in turn might
access a resource written in managed 1icrosoft 2isual BB or any other
.$!T language. This language interoperability extends to full ob5ect-
oriented inheritance. A 2isual Basic .$!T class might be derived from a D
class, for example, or vice versa.
This level of cross-language compatibility is possible because of the
common language runtime. 8hen a .$!T application is compiled, it is
converted from the language in which it was written 92isual Basic .$!T,
D, or any other .$!T-compliant language: to 1icrosoft &ntermediate
%anguage 913&% or &%:. 13&% is a low-level language that the common
language runtime can read and understand. Because all .$!T executables
and +%%s exist as 13&%, they can freely interoperate. The ommon
%anguage 3pecification 9%3: defines the minimum standards to which
.$!T language compilers must conform. Thus, the %3 ensures that any
source code successfully compiled by a .$!T compiler can interoperate with
the .$!T .ramework.
The T3 ensures type compatibility between .$!T components. Because
.$!T applications are converted to &% prior to deployment and execution, all
primitive data types are represented as .$!T types. Thus, a 2isual Basic
&nteger and a D int are both represented in &% code as a 3ystem.&ntE0.
Because both languages use a common type system, it is possible to transfer
data between components and avoid time-consuming conversions or hard-to-
find errors.
2isual 3tudio .$!T ships with languages such as 2isual Basic .$!T, 2isual
D, and 2isual BB with managed extensions, as well as the >3cript
scripting language. )ou can also write managed code for the .$!T
.ramework in other languages. Third-party tools and compilers exist for
.ortran, obol, 4erl, and a host of other languages. All of these languages
share the same cross-language compatibility and inheritability. Thus, you
can write code for the .$!T .ramework in the language of your choice, and
it will be able to interact with code written for the .$!T .ramework in any
other language.
"#'( Frame&or) Arc*itectre
The 3tructure of a .$!T Application
To understand how the common language runtime manages code execution,
you must examine the structure of a .$!T application. The primary unit of
a .$!T application is the assembly. An assembly is a self-describing
collection of code, resources, and metadata. The assembly manifest contains
information about what is contained within the assembly. The assembly
manifest provides#
&dentity information, such as the assemblyCs name and version number
A list of all types exposed by the assembly
A list of other assemblies re6uired by the assembly
A list of code access security instructions, including permissions
re6uired by the assembly and permissions to be denied the assembly
!ach assembly has one and only one assembly manifest, and it contains all
the description information for the assembly. <owever, the assembly
manifest can be contained in its own file or within one of the assemblyCs
modules.
An assembly contains one or more modules. A module contains the code
that makes up your application or library, and it contains metadata that
describes that code. 8hen you compile a pro5ect into an assembly, your
code is converted from high-level code to &%. Because all managed code is
first converted to &% code, applications written in different languages can
easily interact. .or example, one developer might write an application in
2isual D that accesses a +%% in 2isual Basic .$!T. Both resources will be
converted to &% modules before being executed, thus avoiding any language-
incompatibility issues.
!ach module also contains a number of types. Types are templates that
describe a set of data encapsulation and functionality. There are two kinds of
types# reference types 9classes: and value types 9structures:. These types are
discussed in greater detail in %esson 0 of this chapter. !ach type is described
to the common language runtime in the assembly manifest. A type can
contain fields, properties, and methods, each of which should be related to a
common functionality. .or example, you might have a class that represents a
bank account. &t contains fields, properties, and methods related to the
functions needed to implement a bank account. A field represents storage of
a particular type of data. One field might store the name of an account
holder, for example. 4roperties are similar to fields, but properties usually
provide some kind of validation when data is set or retrieved. )ou might
have a property that represents an account balance. 8hen an attempt is made
to change the value, the property can check to see if the attempted change is
greater than a predetermined limit. &f the value is greater than the limit, the
property does not allow the change. 1ethods represent behavior, such as
actions taken on data stored within the class or changes to the user interface.
ontinuing with the bank account example, you might have a Transfer
method that transfers a balance from a checking account to a savings
account, or an Alert method that warns users when their balances fall below
a predetermined level.
CL+ 'xection ,odel
ompilation and !xecution of a .$!T Application
8hen you compile a .$!T application, it is not compiled to binary machine
codeF rather, it is converted to &%. This is the form that your deployed
application takesGone or more assemblies consisting of executable files and
+%% files in &% form. At least one of these assemblies will contain an
executable file that has been designated as the entry point for the
application.
8hen execution of your program begins, the first assembly is loaded into
memory. At this point, the common language runtime examines the
assembly manifest and determines the re6uirements to run the program. &t
examines security permissions re6uested by the assembly and compares
them with the systemCs security policy. &f the systemCs security policy does
not allow the re6uested permissions, the application will not run. &f the
application passes the systemCs security policy, the common language
runtime executes the code. &t creates a process for the application to run in
and begins application execution. 8hen execution starts, the first bit of code
that needs to be executed is loaded into memory and compiled into native
binary code from &% by the common language runtimeCs >ust-&n-Time 9>&T:
compiler. Once compiled, the code is executed and stored in memory as
native code. Thus, each portion of code is compiled only once when an
application executes. 8henever program execution branches to code that has
not yet run, the >&T compiler compiles it ahead of execution and stores it in
memory as binary code. This way, application performance is maximi7ed
because only the parts of a program that are executed are compiled.
0# The .$!T Base lass %ibrary
The .$!T base class library is a collection of ob5ect-oriented types
and interfaces that provide ob5ect models and services for many of the
complex programming tasks you will face. 1ost of the types
presented by the .$!T base class library are fully extensible, allowing
you to build types that incorporate your own functionality into your
managed code.
The .$!T .ramework base class library contains the base classes that
provide many of the services and ob5ects you need when writing your
applications. The class library is organi7ed into namespaces. A namespace is
a logical grouping of types that perform related functions. .or example, the
3ystem.8indows..orms namespace contains all the types that make up
8indows forms and the controls used in those forms.
$amespaces are logical groupings of related classes. The namespaces in
the .$!T base class library are organi7ed hierarchically. The root of the
.$!T .ramework is the 3ystem namespace. Other namespaces can be
accessed with the period operator. A typical namespace construction appears
as follows#
3ystem
3ystem.+ata
3ystem.+ata.3"%lient
The first example refers to the 3ystem namespace. The second refers to the
3ystem.+ata namespace. The third example refers to the
3ystem.+ata.3"%lient namespace. Table -.- introduces some of the more
commonly used .$!T base class namespaces.
Table ---. 'epresentative .$!T $amespaces
$amespace +escription
3ystem
This namespace is the root for many of the low-level
types re6uired by the .$!T .ramework. &t is the root for
primitive data types as well, and it is the root for all the
other namespaces in the .$!T base class library.
3ystem.ollections
This namespace contains classes that represent a variety
of different container types, such as Array%ist,
3orted%ist, "ueue, and 3tack. )ou also can find abstract
classes, such as ollectionBase, which are useful for
implementing your own collection functionality.
3ystem.omponent1odel
This namespace contains classes involved in
component creation and containment, such as
attributes, type converters, and license providers.
3ystem.+ata
This namespace contains classes re6uired for
database access and manipulations, as well as
additional namespaces used for data access.
3ystem.+ata.ommon
This namespace contains a set of classes that are
shared by the .$!T managed data providers.
3ystem.+ata.Ole+b
This namespace contains classes that make up the
managed data provider for O%! +B data access.
3ystem.+ata.3"%lient
This namespace contains classes that are
optimi7ed for interacting with 1icrosoft 3"%
3erver.
3ystem.+rawing
This namespace exposes (+&B functionality and
provides classes that facilitate graphics rendering.
3ystem.&O
&n this namespace, you will find types for
handling file system &AO.
3ystem.1ath
This namespace is home to common mathematics
functions such as extracting roots and
trigonometry.
3ystem.'eflection
This namespace provides support for obtaining
information and dynamic creation of types at
runtime.
3ystem.3ecurity
This namespace is home to types dealing with
permissions, cryptography, and code access
security.
3ystem.Threading
This namespace contains classes that facilitate the
implementation of multithreaded applications.
3ystem.8indows..orms
This namespace contains types involved in
creating standard 8indows applications. lasses
that represent forms and controls reside here as
well.
The namespace names are self-descriptive by design. 3traightforward names
make the .$!T .ramework easy to use and allow you to rapidly familiari7e
yourself with its contents.
'eference Types and 2alue Types
Types in the .$!T .ramework come in two varieties# value types and
reference types. The primary difference between value types and reference
types has to do with the way variable data is accessed. To understand this
difference, a little background on memory dynamics is re6uired.
Application data memory is divided into two primary components, the stack
and the heap. The stack is an area of memory reserved by the application to
run the program. The stack is analogous to a stack of dinner plates. 4lates
are placed on the stack one on top of another. 8hen a plate is removed from
the stack, it is always the last one to have been placed on top that is removed
first. 3o it is with program variables. 8hen a function is called, all the
variables used by the function are pushed onto the stack. &f that function
calls additional functions, it pushes additional variables onto the stack.
8hen the most recently called function terminates, all of its variables go out
of scope 9meaning that they are no longer available to the application: and
are popped off the stack. 1emory consumed by those variables is then freed
up, and program execution continues.
The heap, on the other hand, is a separate area of memory reserved for the
creation of reusable ob5ects. The common language runtime manages
allocation of heap memory for ob5ects and controls the reclamation of
memory from unused ob5ects through garbage collection.
All the data associated with a value type is allocated on the stack. 8hen a
variable of a value type goes out of scope, it is destroyed and its memory is
reclaimed. A variable of a reference type, on the other hand, exists in two
memory locations. The actual ob5ect data is allocated on the heap. A variable
containing a pointer to that ob5ect is allocated on the stack. 8hen that
variable is called by a function, it returns the memory address for the ob5ect
to which it refers. 8hen that variable goes out of scope, the ob5ect reference
is destroyed but the ob5ect itself is not. &f any other references to that ob5ect
exist, the ob5ect remains intact. &f the ob5ect is left without any references, it
is sub5ect to garbage collection. 93ee %esson H of this chapter.:
!xamples of value types include primitives, such as &nteger 9int:, Boolean
9bool:, har 9char:, and so on, as well as user-defined types such as
3tructure 9struct: and !numeration 9enum:. lasses represent the ma5ority of
reference types. Other reference types include the interface, delegate, and
array types. lasses and structures are discussed in %esson E of this chapter,
and other reference and value types are discussed in hapter E.
*sing .$!T .ramework Types in )our Application
8hen you begin writing an application, you automatically begin with a
reference to the .$!T .ramework base class library. )ou reference it so that
your application is aware of the base class library and is able to create
instances of the types represented by it.
2alue Types
int my&ntegerF
This line tells the runtime to allocate the appropriate amount of memory to
hold an integer variable. Although this line creates the variable, it does not
assign a value to it. )ou can assign a value using the assignment operator, as
follows#
my&nteger I ,0F
)ou can also choose to assign a value to a variable upon creation, as shown
in this example#
int my&nteger I ,0F
'eference Types
reating an instance of a type is a two-step process. The first step is to
declare the variable as that type, which allocates the appropriate amount of
memory for that variable but does not actually create the ob5ect. The
following syntax declares an ob5ect#
3ystem.8indows..orms..orm my.ormF
This line tells the runtime to set aside enough memory to hold a .orm
variable and assigns it the name my.orm, but it does not actually create the
.orm ob5ect in memory. The second step, called instantiation, actually
creates the ob5ect. An example of instantiation follows#
my.orm I new 3ystem.8indows..orms..orm9:F
This line makes a call to the constructor method of the type
3ystem.8indows..orms..orm by way of the $ew 9new: keyword. The
constructor is a special method that is invoked only at the beginning of an
ob5ectCs lifetime. &t contains any code that must be executed for the ob5ect to
work 9assigning values to properties, for example:. &f any parameters were
re6uired by the constructor, they would be contained within the parentheses
at the end of the line. The following example shows declaration and
instantiation of a hypothetical 8idget class that re6uires a string as a
parameter in the constructor.
8idget my8idgetF
my8idget I new 8idget9JThis string is re6uired by the constructorJ:F
&f desired, you can also combine both declaration and instantiation into a
single statement. By declaring and instantiating an ob5ect in the same line,
you reserve the memory for the ob5ect and immediately create the ob5ect that
resides in that memory. Although there was a significant performance
penalty for this shortcut in previous versions of 2isual Basic, 2isual
Basic .$!T and 2isual D are optimi7ed to allow this behavior without any
performance loss. The following example shows the one-step declaration
and instantiation of a new .orm#
3ystem.8indows..orms..orm my.orm I new
3ystem.8indows..orms..orm9:F
Both value types and reference types must be initiali7ed before use. .or
class and structure fields in 2isual Basic .$!T, types are initiali7ed with
default values on declaration. $umeric value types 9such as integer: and
floating-point types are assigned 7eroF Boolean variables are assigned .alseF
and reference types are assigned to a null reference.
&n D, variables of a reference type have a default value of null. &t is
recommended that you do not rely on the default value. These variables
should not be used until they have been initiali7ed.
*sing 2alue Type and 'eference Type 2ariables
A variable that represents a value type contains all the data represented by
that type. A variable that represents a reference type contains a reference to a
particular ob5ect. This distinction is important. onsider the following
example#
int x, yF
x I -KF
y I xF
x I E/F
AA 8hat is the value of yL
&n this example, two integer variables named x and y are created. ; is
assigned a value of -K, and then y is assigned the value of x. $ext the value
of x is changed to E/, and the 6uestion is posed# what is the value of yL The
answer to this 6uestion might seem obvious, and it is y I -K because x and y
are two separate variables and have no effect on each other when changed.
8hen the line y I x is encountered, the value of x is copied to the value of y,
and there is no further connection between the two variables.
This situation changes, however, in the case of reference types. %etCs
reconsider the previous example using a reference type 9.orm: instead of a
value type.
3ystem.8indows..orms..orm x,yF
x I new 3ystem.8indows..orms..orm9:F
x.Text I JThis is .orm -JF
y I xF
x.Text I JThis is .orm 0JF
AA 8hat value does y.Text returnL
8hat value does y.Text returnL This time, the answer is less obvious.
Because 3ystem.8indows..orms..orm is a reference type, the variable x
does not actually contain a .ormF rather, it points to an instance of a .orm.
8hen the line y I x is encountered, the runtime copies the reference from
variable x to y. Thus, the variables x and y now point to the same instance of
.orm. Because these two variables refer to the same instance of the ob5ect,
they will return the same values for properties of that ob5ect. Thus, y.Text
returns MThis is .orm 0N.
The &mports and *sing 3tatements
*p to this point of the chapter, if you wanted to access a type in the .$!T
.ramework base class library, you had to use the full name of the type,
including every namespace to which it belonged. .or example#
3ystem.8indows..orms..orm
This is called the fully-6ualified name, meaning it refers both to the class
and to the namespace in which it can be found. )ou can make your
development environment MawareN of various namespaces by using the
&mports 92isual Basic .$!T: or using 92isual D: statement. This techni6ue
allows you to refer to a type using only its generic name and to omit the
6ualifying namespaces. Thus, you could refer to
3ystem.8indows..orms..orm as simply .orm. &n 2isual Basic .$!T, the
&mports statement must be placed at the top of the code window, preceding
any other statement 9except Option:. &n 2isual D, the using statement must
occur before any other namespace element, such as a class or struct. This
example demonstrates use of this statement#
using 3ystem.8indows..ormsF
8hen two types of the same name exist in more than one imported
namespace, you must use the fully 6ualified name to avoid a naming
conflict. Thus, if you are using 1y$ame3paceOne and 1y$ame3paceTwo,
and each contains a 8idget class, you would have to refer to
1y$ame3paceOne.8idget or 1y$ame3paceTwo.8idget to ensure the
correct result.
&n D, you can resolve namespace conflicts such as these by creating an
alias. An alias allows you to choose one name to refer to another class. )ou
create an alias using the using keyword, as shown below#
using myAlias I 1y$ame3paceTwo.8idgetF
After implementing an alias, you can use it in code to represent the aliased
class. .or example#
AA )ou can now refer to 1y$ame3paceTwo as myAlias. The
AA following two lines produce the same result#
1y$ame3paceTwo.8idget another8idget I new 1y$ame3paceTwo.8idg
et9: F
myAlias another8idget I new myAlias9: F
)ou cannot create aliases for types in this manner in 2isual Basic .$!T.
'eferencing !xternal %ibraries
)ou might want to use class libraries not contained by the .$!T .ramework,
such as libraries developed by third-party vendors or libraries you
developed. To access these external libraries, you must create a reference.
To create a reference to an external library
-. &n the 3olution !xplorer, right-click the 'eferences node of your
pro5ect.
0. .rom the pop-up menu, choose Add 'eference. The Add 'eference
dialog box appears.
E. hoose the appropriate tab for the library you want to reference. .$!T
libraries are available on the .$!T tab. %egacy O1 libraries appear
on the O1 tab, and local 2isual 3tudio pro5ects appear on the
4ro5ects tab.
,. %ocate the library you want to reference, and double-click it to add it
to the 3elected components box. lick OO to confirm the choice of
that reference.
-ntrodction to .b/ect0.riented Programming
4rogramming in the .$!T .ramework environment is done with ob5ects.
Ob5ects are programmatic constructs that represent packages of related data
and functionality. Ob5ects are self-contained and expose specific
functionality to the rest of the application environment without detailing the
inner workings of the ob5ect itself. Ob5ects are created from a template
called a class. The .$!T base class library provides a set of classes from
which you can create ob5ects in your applications. )ou also can use the
1icrosoft 2isual 3tudio programming environment to create your own
classes. This lesson introduces you to the concepts associated with ob5ect-
oriented programming.
Ob5ects, 1embers, and Abstraction
An ob5ect is a programmatic construct that represents something. &n the real
world, ob5ects are cars, bicycles, laptop computers, and so on. !ach of these
items exposes specific functionality and has specific properties. &n your
application, an ob5ect might be a form, a control such as a button, a database
connection, or any of a number of other constructs. !ach ob5ect is a
complete functional unit, and contains all of the data and exposes all of the
functionality re6uired to fulfill its purpose. The ability of programmatic
ob5ects to represent real-world ob5ects is called abstraction.
lasses Are Templates for Ob5ects
lasses can be thought of as blueprints for ob5ects# they define all of the
members of an ob5ect, define the behavior of an ob5ect, and set initial values
for data when appropriate. 8hen a class is instantiated, an in-memory
instance of that class is created. This instance is called an ob5ect. To review,
a class is instantiated using the $ew 9new: keyword as follows#
8hen an instance of a class is created, a copy of the instance data defined by
that class is created in memory and assigned to the reference variable.
&ndividual instances of a class are independent of one another and represent
separate programmatic constructs. There is generally no limit to how many
copies of a single class can be instantiated at any time. To use a real-world
analogy, if a car is an ob5ect, the plans for the car are the class. The plans
can be used to make any number of cars, and changes to a single car do not,
for the most part, affect any other cars.
Ob5ects and 1embers
Ob5ects are composed of members. 1embers are properties, fields, methods,
and events, and they represent the data and functionality that comprise the
ob5ect. .ields and properties represent data members of an ob5ect. 1ethods
are actions the ob5ect can perform, and events are notifications an ob5ect
receives from or sends to other ob5ects when activity happens in the
application.
To continue with the real-world example of a car, consider that a ar ob5ect
has fields and properties, such as olor, 1ake, 1odel, Age, (as%evel, and
so on. These are the data that describe the state of the ob5ect. A ar ob5ect
might also expose several methods, such as Accelerate, 3hift(ears, or Turn.
The methods represent behaviors the ob5ect can execute. And events
represent notifications. .or example, a ar ob5ect might receive an
!ngineOverheating event from its !ngine ob5ect, or it might raise a rash
event when interacting with a Tree ob5ect.
Ob5ect 1odels
3imple ob5ects might consist of only a few properties, methods, and perhaps
an event or two. 1ore complex ob5ects might re6uire numerous properties
and methods and possibly even subordinate ob5ects. Ob5ects can contain and
expose other ob5ects as members. .or example, the TextBox control exposes
a .ont property, which consists of a .ont ob5ect. 3imilarly, every instance of
the .orm class contains and exposes a ontrols collection that comprises all
of the controls contained by the form. The ob5ect model defines the
hierarchy of contained ob5ects that form the structure of an ob5ect.
An ob5ect model is a hierarchical organi7ation of subordinate ob5ects
contained and exposed within a main ob5ect. To illustrate, letCs revisit the
example of a car as an ob5ect. A car is a single ob5ect, but it also consists of
subordinate ob5ects. A ar ob5ect might contain an !ngine ob5ect, four
8heel ob5ects, a Transmission ob5ect, and so on. The composition of these
subordinate ob5ects directly affects how the ar ob5ect functions as a whole.
.or example, if the ylinders property of the !ngine subordinate ob5ect is
e6ual to ,, the ar will behave differently than a ar whose !ngine has a
ylinders property value of P. ontained ob5ects can have subordinate
ob5ects of their own. .or example, the contained !ngine ob5ect might
contain several 3park4lug ob5ects.
!ncapsulation
!ncapsulation is the concept that implementation of an ob5ect is independent
of its interface. 4ut another way, an application interacts with an ob5ect
through its interface, which consists of its public properties and methods. As
long as this interface remains constant, the application can continue to
interact with the component, even if implementation of the interface was
completely rewritten between versions.
Ob5ects should only interact with other ob5ects through their public methods
and properties. Thus, ob5ects should contain all of the data they re6uire, as
well as all of the functionality that works with that data. The internal data of
an ob5ect should never be exposed in the interfaceF thus, fields rarely should
be 4ublic 9public:.
'eturning to the ar example. &f a ar ob5ect interacts with a +river ob5ect,
the ar interface might consist of a (o.orward method, a (oBackward
method, and a 3top method. This is all the information that the +river needs
to interact with the ar. The ar might contain an !ngine ob5ect, for
example, but the +river doesnCt need to know about the !ngine ob5ectGall
the +river cares about is that the methods can be called and that they return
the appropriate values. Thus, if one !ngine ob5ect is exchanged for another,
it makes no difference to the +river as long as the interface continues to
function correctly.
4olymorphism
4olymorphism is the ability of different classes to provide different
implementations of the same public interfaces. &n other words,
polymorphism allows methods and properties of an ob5ect to be called
without regard for the particular implementation of those members. .or
example, a +river ob5ect can interact with a ar ob5ect through the ar
public interface. &f another ob5ect, such as a Truck ob5ect or a 3portsar
ob5ect, exposes the same public interface, the +river ob5ect can interact with
them without regard to the specific implementation of that interface. There
are two principal ways through which polymorphism can be provided#
interface polymorphism and inheritance polymorphism.
&nterface 4olymorphism
An interface is a contract for behavior. !ssentially, it defines the members a
class should implement, but states nothing at all about the details of that
implementation. An ob5ect can implement many different interfaces, and
many diverse classes can implement the same interface. All ob5ects
implementing the same interface are capable of interacting with other
ob5ects through that interface. .or example, the ar ob5ect in the previous
examples might implement the &+rivable interface 9by convention, interfaces
usually begin with &:, which specifies the (o.orward, (oBackward, and
<alt methods. Other classes, such as Truck, .orklift, or Boat might
implement this interface and thus are able to interact with the +river ob5ect.
The +river ob5ect is unaware of which interface implementation it is
interacting withF it is only aware of the interface itself. &nterface
polymorphism is discussed in detail in %esson E.
&nheritance 4olymorphism
&nheritance allows you to incorporate the functionality of a previously
defined class into a new class and implement different members as needed.
A class that inherits another class is said to derive from that class, or to
inherit from that class. A class can directly inherit from only one class,
which is called the base class. The new class has the same members as the
base class, and additional members can be added as needed. Additionally,
the implementation of base members can be changed in the new class by
overriding the base class implementation. &nherited classes retain all the
characteristics of the base class and can interact with other ob5ects as though
they were instances of the base class. .or example, if the ar class is the
base class, a derived class might be 3port scar. The 3port scar class might be
the base class for another derived class, the onvertible3portsar. !ach
newly derived class might implement additional members, but the
functionality defined in the original ar class is retained.
+eqirements:
<ardware # 4 with 0 (B hard-disk and 0KH 1B 'A1
Operating 3ystem # 8indows 0///, ;4, 0//E server
3oftware # A34.$et, D.$et
Backend # 36l 3erver 0///A0//K