Why Use a Database?

The following are some of the reasons why you would use databases:
•  Compactness: Databases help you maintain large amounts of data and thus completely replace voluminous paper files.
•  Speed: Searches for a particular piece of data or information in a database are
much faster than sorting through piles of paper.

•  Less drudgery: It is a dull work to maintain files by hand; using a database completely eliminates such maintenance.
•  Currency: Database systems can easily be updated and so provide accurate information all the time and on demand.

Benefits of Using a RelationalDatabase Management System 

RDBMSs offer various benefits by controlling the following:
•  Redundancy: RDBMSs prevent you from having duplicate copies of the same data,
which takes up disk space unnecessarily.
•  Inconsistency: Each redundant set of data may no longer agree with other sets of
the same data. When an RDBMS removes redundancy, inconsistency cannot
occur.
•  Data integrity: Data values stored in the database must satisfy certain types of
consistency constraints.
•  Data atomicity: In event of a failure, data is restored to the consistent state it
existed in prior to the failure. For example, fund transfer activity must be atomic.
•  Access anomalies: RDBMSs prevent more than one user from updating the same
data simultaneously; such concurrent updates may result in inconsistent data.
•  Data security: Not every user of the database system should be able to access all
the data. Security refers to the protection of data against any unauthorized access.
•  Transaction processing: A transaction is a sequence of database operations that
represents a logical unit of work. In RDBMSs, a transaction either commits all the
changes or rolls back all the actions performed until the point at which the failure
occurred.
•  Recovery: Recovery features ensure that data is reorganized into a consistent state
after a transaction fails.
•  Storage management: RDBMSs provide a mechanism for data storage
management. The internal schema defines how data should be stored.

Comparing Desktop and Server RDBMS Systems 

In the industry today, you’ll mainly work with two types of databases: desktop databases and server
databases
Desktop Databases 
Desktop databases are designed to serve a limited number of users and run on desktop PCs, and they
offer a less-expansive solution wherever a database is required. Chances are you have worked with a
desktop database program; Microsoft SQL Server Express, Microsoft Access, Microsoft FoxPro,
FileMaker Pro, Paradox, and Lotus are all desktop database solutions.
Desktop databases differ from server databases in the following ways: 
•  Less expensive: Most desktop solutions are available for just a few hundred dollars.
In fact, if you own a licensed version of Microsoft Office Professional, you’re
already a licensed owner of Microsoft Access, which is one of the most commonly
and widely used desktop database programs around.
•  User friendly: Desktop databases are quite user friendly and easy to work with,
because they do not require complex SQL queries to perform database operations
(although some desktop databases also support SQL syntax if you want to write
code). Desktop databases generally offer an easy-to-use graphical user interface.
Server Databases 
Server databases are specifically designed to serve multiple users at a time and offer features that allow
you to manage large amounts of data very efficiently by serving multiple user requests simultaneously.
Well-known examples of server databases include Microsoft SQL Server, Oracle, Sybase, and DB2.
The following are some other characteristics that differentiate server databases from their desktop
counterparts:
•  Flexibility: Server databases are designed to be very flexible and support multiple
platforms, respond to requests coming from multiple database users, and perform
any database management task with optimum speed.
•  Availability: Server databases are intended for enterprises, so they need to be
available 24/7. To be available all the time, server databases come with some highavailability features, such as mirroring and log shipping.
•  Performance: Server databases usually have huge hardware support, so servers
running these databases have large amountsof RAM and multiple CPUs. This is
why server databases support rich infrastructure and give optimum performance.
•  Scalability: This property allows a server database to expand its ability to process
and store records even if it has grown tremendously.

Using Layout Controls

Although you can use fixed positioning to place controls on a WPF window, it’s
positioning usually works well for a fixed resolution size but it doesn’t scale we
To overcome the limitations of fixed positioning, WPF offers several layout con
position other controls within it using a relative positioning format. One of the
other controls is the Grid. As seen previous post, a Grid control contains columns
its child controls. The height and width of the columns and rows can be set to a
takes up as much space as needed by the contained control. The *setting take
The Grid control is often used to lay out data entry forms. The following code l
collect user information. The resulting form (in the Visual Studio designer) is s
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
<RowDefinition Height="28" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="200" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<Label Grid.Row="0" Grid.Column="0" Content="Name:"/>
<Label Grid.Row="1" Grid.Column="0" Content="Old Password:"/>
<Label Grid.Row="2" Grid.Column="0" Content="New Password:"/>
<Label Grid.Row="3" Grid.Column="0" Content="Confirm Password:
<TextBox Grid.Column="1" Grid.Row="0" Margin="3" />
<TextBox Grid.Column="1" Grid.Row="1" Margin="3" />
<TextBox Grid.Column="1" Grid.Row="2" Margin="3" />
<TextBox Grid.Column="1" Grid.Row="3" Margin="3" />
<Button Grid.Column="1" Grid.Row="4" HorizontalAlignment="Righ
MinWidth="80" Margin="0,0,0,8" Content="Submit" />
</Grid>

XAML

WPF user interfaces are built using a declarative markup language called XAML. XAML declares the controls that will
make up the interface. An opening angle bracket (<) followed by the name of the control type and a closing bracket
define the control. For example, the following markup defines a button control inside a Grid.
<Grid>

<Button/>

</Grid>
Notice the Grid needs a formal closing tag because it contains the Button control. Since the Button control does not contain any other elements, you can use a forward slash (/) in front of the end bracket to close it
The next step is to define the properties of the controls. For example, you may want to set the background colour of the button to red and write some text on it. The properties of the control are set by using attribute syntax, which consists of the property name followed by an equal sign and the attribute value in quotation marks. The following mark-up shows the Button control with some attributes added:

<Grid>
<Button Content="Click Me" Background="Red"/>
</Grid>
For some properties of an object element a syntax known as property element syntax is used. The syntax for the property element start tag is <typeName.propertyName>. For example, you can create rows and columns in the layout grid to control placement of controls in the grid, as shown:

<Grid.ColumnDefinitions>
<ColumnDefinition Width="100" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition Height="25" />
<RowDefinition Height="25" />
<RowDefinition Height="25" />
</Grid.RowDefinitions>
Controls are positioned in the grid by including a Grid.Rowand Grid.Columnattribute, as shown:
<Label Grid.Column="0" Grid.Row="0" Content="Name:" />
<Label Grid.Column="0" Grid.Row="1" Content="Password:" />
<TextBox Name="txtName" Grid.Column="1" Grid.Row="0"/>
<TextBox Name="txtPassword" Grid.Column="1" Grid.Row="1"/>
<Button Grid.Column="1" Grid.Row="3"
Content="Click Me" HorizontalAlignment="Right"
MinWidth="80" Background="Red"/>

WHAT IS A CASE STUDY?

The term “case study” appears every now and then in the title of software engineering
research papers. These papers have in common that they study a specific case, in
contrast to a sample from a specified population. However, the presented studies
range from very ambitious and well-organized studies in the field of operations
(in vivo) to small toy examples in a university lab (in vitro) that claim to be case
studies. This variation creates confusion, which should be addressed by increased
knowledge about case study methodology.
Case study is a commonly used research strategy in areas such as psychology,
sociology, political science, social work, business, and community planning
In these areas, case studies are conducted with the objectives of not only increasing knowledge (e.g., knowledge about individuals, groups,
and organizations and about social, political, and related phenomena) but also bringing about change in the phenomenon being studied (e.g. improving education or social
care). Software engineering research has similar high-level objectives, that is, to better understand how and why software engineering should be undertaken and, with
this knowledge, to seek to improve the software engineering process and the resultant
software products.
There are different taxonomies used to classify research in software engineering.
The term case study is used in parallel with terms like field study and observational
study, each focusing on a particular aspect of the research methodology. For example,
Case studies offer an approach that does not require a strict boundary between the
object of study and its environment. Case studies do not generate the same results
on, for example, causal relationships, as controlled experiments do, but they provide
a deeper understanding of the phenomena under study. As they are different from
analytical and controlled empirical studies, case studies have been criticized for being
of less value, being impossible to generalize from, being biased by researchers, and so
on. This critique can be met by applying proper research methodology practices and
by reconsidering that knowledge is more than statistical significance.
However, the research community has to learn more about the case study methodology
in order to conduct, report, review, and judge it properly.

HISTORY:

The term case study first appeared in software engineering journal papers in the
late 1970s. At that time, a case study was typically a demonstration case, that
is, a case that demonstrated the implementation of some software technology or
programming concept.
In the mid- to late-1980s, papers started to report case studies of a broader range
of software development phenomena, for example, Alexander and Potter’study
of formal specifications and rapid prototying. For these types of papers, the term case
study refers to a self-experienced and self-reported investigation. Throughout the
1990s the scale of these “self investigations” increased and there were, for example, a
series of papers reporting case studies of software process improvement in large and
multinational organizations such as Boeing, Hughes, Motorola, NASA, and Siemens.
Case studies based on the external and independent observation of a software
engineering activity first appeared in the late 1980s, for example, Boehm and
Ross’s “extensive case study” of the introduction of new information
systems into a large industrial corporation in an emerging nation. These case studies,
however, did not direct attention at case study methodology that is, at the design,

conduct, and reporting of the case study
The first case study papers that explicitly report the study methodology were
published in 1988: Curtis et al.’s [37] field study of software design activities and
Swanson and Beath’s [199] multiple case study of software maintenance. Given the
status of case study research in software engineering at the time, it is not surprising that Swanson and Beath were actually researchers in a school of management
in the United States, and were not software engineering researchers. Swanson and
Beath use their multiple case studies to illustrate a number of challenges that arise
when conducting case studies research, and they also present methodological lessons.
Their paper therefore appears to be the first of its kind in the software engineering
research community that explicitly discusses the challenge of designing, conducting,
and reporting case study research.
During the 1990s, both demonstration studies and genuine case studies (as we
define them here) were published, although only in small numbers. Glass et al.
analyzed software engineering publications in six major software engineering journals
for the period 1995–1999 and found that only 2.2% of these publications reported case
studies .Much more recently, a sample of papers from Sjøberg et al.’s large systematic review of experimental studies in software engineering  were analysed
by Holt .She classified 12% of the sample as case studies. This compares to
1.9% of papers classified as formal experiments in the Sjøberg study. But differences
in the design of these reviews make it hard to properly compare the reviews and draw
firm conclusions.
The first recommendations, by software engineering researchers, regarding case
study methodology were published in the mid-1990s . However, these recommendations focus primarily on the use of quantitative data. In the late 1990s, Seaman
published guidelines on qualitative research . Then, in the early twenty-first

century, a broader set of guidelines on empirical research were published by Kitchen ham et al. Sim et al. arranged a workshop on the topic, which was summarized
in Empirical Software Engineering, Wohlin et al. provided a brief introduction
to case studies among other empirical methods , and Dittrich et al. edited a special issue of Information and Software Technology on qualitative software engineering
There is a very wide range of activities in software engineering, such as development, operation, and maintenance of software and related artifacts as well as the
management of these activities. A frequent aim of software engineering research is to
investigate how this development, operation, and maintenance is conducted, and also
managed, by software engineers and other stakeholders under different conditions.
With such a wide range of activities, and a wide range of software products being
developed, there is a very diverse range of skills and experience needed by the actors
undertaking these activities.
Software engineering is also distinctive in the combination of diverse topics that
make up the discipline
Many of the interim products are produced either intentionally by the actors (e.g.,
the minutes of meetings) or automatically by technology (e.g., updates to a version
of control system). Therefore, one of the distinctive aspects of software engineering
is the raw data that are naturally, and often automatically, generated by the activities
and technologies.
There are clear overlaps with other disciplines, such as psychology, management,
business, and engineering, but software engineering brings these other disciplines
together in a unique way, a way that needs to be studied with research methods
tailored to the specifics of the discipline
Case studies investigate phenomena in their real-world settings, for example, new
technologies, communication in global software development, project risk and failure
factors, and so on. Hence, the researcher needs to consider not only the practical
requirements and constraints from the researcher’s perspective, but also the objectives
and resource commitments of the stakeholders who are likely to be participating in,
or supporting, the case study. Also, practitioners may want to intervene in future
projects – that is, change the way things are done in future projects – on the basis
of the outcomes from the case studies, and often software engineering managers
are interested in technology interventions, such as adopting a new technology

the above content is taken from 
" Case Study Research in Software Engineering: Guidelines and Examples "

Constructors in Object Oriented Programming

Constructors may be a new concept for structured programmers. Although constructors are not
normally used in non-OO languages such as COBOL, C, and Basic, the struct , which is part of
C/C++, does include constructors.In some OO languages, such as Java and C#, constructors are
methods that share the same name as the class. Visual Basic .NET uses the designation New
and Objective-C uses the init keyword.
 For example, a constructor for the Cabbie class  would look like this:
 public Cabbie(){
 /* code to construct the object */
 }
 The compiler will recognize that the method name is identical to the class name and consider
the method a constructor.
 Note that in this Java code (as with C# and C++), a constructor does not have a return value. If
you provide a return value, the compiler will not treat the method as a constructor.
 For example, if you include the following code in the class, the compiler will not consider this
a constructor because it has a return value—in this case, an integer:
 public int Cabbie(){
 /* code to construct the object */
 }
 This syntax requirement can cause problems because this code will compile but will not behave
as expected.

Constructors may be a new concept for structured programmers. Although constructors are not 

normally used in non-OO languages such as COBOL, C, and Basic, the struct , which is part of 

C/C++, does include constructors. In the first two chapters, we alluded to these special methods 

that are used to construct objects. In some OO languages, such as Java and C#, constructors are 

methods that share the same name as the class. Visual Basic .NET uses the designation New 

and Objective-C uses the init keyword. As usual, we will focus on the concepts of constructors 

and not cover the specific syntax of all the languages. Let’s take a look at some Java code that 

implements a constructor. 

 For example, a constructor for the Cabbie class we covered in Chapter 2 would look like this: 

 public Cabbie(){

 /* code to construct the object */

 } 

 The compiler will recognize that the method name is identical to the class name and consider 

the method a constructor. 54 Chapter 3 Advanced Object-Oriented Concepts

 Caution 

 Note that in this Java code (as with C# and C++), a constructor does not have a return value. If 

you provide a return value, the compiler will not treat the method as a constructor. 

 For example, if you include the following code in the class, the compiler will not consider this 

a constructor because it has a return value—in this case, an integer: 

 public int Cabbie(){

 /* code to construct the object */

 } 

 This syntax requirement can cause problems because this code will compile but will not behave 

as expected. 

Constructors may be a new concept for structured programmers. Although constructors are not 

normally used in non-OO languages such as COBOL, C, and Basic, the struct , which is part of 

C/C++, does include constructors. In the first two chapters, we alluded to these special methods 

that are used to construct objects. In some OO languages, such as Java and C#, constructors are 

methods that share the same name as the class. Visual Basic .NET uses the designation New 

and Objective-C uses the init keyword. As usual, we will focus on the concepts of constructors 

and not cover the specific syntax of all the languages. Let’s take a look at some Java code that 

implements a constructor. 

 For example, a constructor for the Cabbie class we covered in Chapter 2 would look like this: 

 public Cabbie(){

 /* code to construct the object */

 } 

 The compiler will recognize that the method name is identical to the class name and consider 

the method a constructor. 54 Chapter 3 Advanced Object-Oriented Concepts

 Caution 

 Note that in this Java code (as with C# and C++), a constructor does not have a return value. If 

you provide a return value, the compiler will not treat the method as a constructor. 

 For example, if you include the following code in the class, the compiler will not consider this 

a constructor because it has a return value—in this case, an integer: 

 public int Cabbie(){

 /* code to construct the object */

 } 

 This syntax requirement can cause problems because this code will compile but will not behave 

as expected. 

When Is a Constructor Called? 

 When a new object is created, one of the first things that happens is that the constructor is 

called. Check out the following code: 

 Cabbie myCabbie = new Cabbie(); 

 The new keyword creates a new instance of the Cabbie class, thus allocating the required 

memory. Then the constructor itself is called, passing the arguments in the parameter list. The 

constructor provides the developer the opportunity to attend to the appropriate initialization. 

 Thus, the code new Cabbie() will instantiate a Cabbie object and call the Cabbie method, 

which is the constructor. 

What’s Inside a Constructor? 

Perhaps the most important function of a constructor is to initialize the memory allocated 

when the new keyword is encountered. In short, code included inside a constructor should set 

the newly created object to its initial, stable, safe state. 

 For example, if you have a counter object with an attribute called count , you need to set count 

to zero in the constructor: 

 count = 0; 

The Default Constructor 

 If you write a class and do not include a constructor, the class will still compile, and you can 

still use it. If the class provides no explicit constructor, a default constructor will be provided. 

It is important to understand that at least one constructor always exists, regardless of whether 

you write a constructor yourself. If you do not provide a constructor, the system will provide a 

default constructor for you. 

 Besides the creation of the object itself, the only action that a default constructor takes is to 

call the constructor of its superclass. In many cases, the superclass will be part of the language 

framework, like the Object class in Java. For example, if a constructor is not provided for the 

 

public Cabbie(){

 super();

 } 

If you were to decompile the bytecode produced by the compiler, you would see this code. The 

compiler actually inserts it. 

Using Multiple Constructors

public class Count {

 

 int count;

public Count()

{

 count = 0;

 }

 } 

 On the one hand, we want to initialize the attribute count to count to zero: We can easily 

accomplish this by having a constructor initialize count to zero as follows: 

 public Count()

{

 count = 0;

 } 

On the other hand, we might want to pass an initialization parameter that allows count to be 

set to various numbers: 

 public Count (int number){

 count = number;

 } 

the above content is taken from the The Object-oriented Thought Process

Links and Associations

A link is a physical or conceptual connection between object instances. In
OMT link is represented by a line labeled with its name as shown in Figure

association

An association describes a group of links with common structure and common 

semantics between two or more classes. Association is represented by a line 

labeled with the association name 

Associations can have role names associated each class connection.Associations can also have qualifiers on the class connections. qualifiers are special attributes that reduce the effective multiplicity

OBJECT MODEL COMPONENTS PART 2

Attribute:

An attribute is a data value held by objects in a class. Each attribute has a 

value for each object instance. This value should be a pure data value, not an 

object. Attributes are listed in the second part of the class box. Attributes may 

or may not be shown; it depends on the level of detail desired. Each attribute 

name may be followed by the optional details such as type and default value. 

An object model should generally distinguish independent base attributes 

from dependent derived attributes. A derived attribute is that which is derived 

from other attributes. For example, age is a derived attribute, as it can be 

derived from date-of-birth and current-date attributes. 

operation

An operation is a function or transformation that may be applied to or by 

objects in a class. Operations are listed in the third part of the class box. 

Operations may or may not be shown; it depends on the level of detail 

desired. Each operation may be followed by optional details such as argument 

list and result type. The name and type of each argument may be given. An 

empty argument list in parentheses shows explicitly that there are no 

arguments. All objects in a class share the same operations. Each operation 

has a target object as an implicit argument. An operation may have 

arguments in addition to its target object, which parameterize the operation. 

The behavior of the operation depends on the class of its target. 

The same operation may be defined for several different classes. However, the

signature (i.e. output type and formal parameter list) must be the same

polymorphism 

An operation may be polymorphic in nature. A polymorphic operation means 

that the same operation takes on different forms in different/same classes. 

Overloading of operators, overloading of functions and overriding of functions 

provided by object-oriented programming languages are all examples of 

polymorphic operations. A method is the implementation of an operation for a 

class. The method depends only on the class of the target object.