1.

0 SOFTWARE CONSTUCTION
1.1 Definition:
Software Construction is the detailed creation of working software through a combination
of coding, verification, unit testing, integration testing and debugging. Construction uses the
output from the design process to build software therein described, and provides an output
to testing. Thus, design, construction and testing are closely intertwined, and very often
overlap.
Software construction typically produces the highest volume of configuration items that
need to be managed in a software project (source files, content, test cases, and so on).
Thus, the software construction is also closely linked to the software configuration
management.












Fig 1


2.0 APPLICATION DEVELOPMENT
Application development is the process of designing, building, and implementing software
applications. It can be done by massive organizations with large teams working on projects,
or by a single freelance developer. Application development defines the process of how the
application is made, and generally follows a standard methodology.

There are lots of factors that go into how application development is done. You must
consider the size of the project, how specific the requirements are, how much the customer
will want to change things, how large the development team is, how experienced the
development team is, and the deadline for the project.

2.1 Types of application development:-

2.1.1 Desktop Application Development
Desktop Application Development provides you a user-friendly, efficient, and customized
desktop application that can run offline, independent of your web browser. These apps help
businesses meet their respective need and provide competitive edge in the growing and

1 | P a g e



fiercely competitive market. As each business has its own unique requirements, custom
developed desktop applications help companies to fulfill their needs and achieve success.
The desktop application can provide you with ways to automate specific business processes
to boost performance, synchronize business processes, and improve employee productivity.
Almost all desktop applications are open for up-gradation with time and offer better data
security and protection from any unauthorized access.

2.1.2 Web Application Development
Web application development is creation of app programs that reside on remote computers
and are delivered to user over the Internet. These apps are sometimes contrasted with
native applications that are developed specifically for a particular platform or device and are
then installed on it.

2.1.3 Mobile Application Development
Mobile application development is a process of creating or making a mobile application to
run on different mobile platforms. Actually, a mobile platform is a mobile operating system.
Google mobile platform is Android, and Apple’s mobile operating system is called iOS.
Windows has Windows mobile and RIM has Blackberry. Each of these platforms has its own
specific regulations, rules and requirements to make mobile application. For example, iOS
mobile apps need the use of Objective C, whereas Android mobile apps use Java.
An experienced application developer knows the intricacies of each platform because it’s
simply not possible to just develop an application and port it over to the next platform. In
addition, you also need to consider what all app stores you wish to highlight your
application.

Application development is closely linked with the software development life-cycle

(SDLC), or application development takes into consideration the steps of a SDLC.

2.2 The basic stages of SDLC are

The steps included in a systems lifecycle for developing a computer application are:

• Planning: Identifying a need, consideration of solution options, and possibly

considering the features of competing applications.
• Analysis: Documenting the functional requirements for the app and anticipating
potential problems that may be encountered.
• Design: Defining how the app will work and what features and components it will
have.
• Construction: This is where the actual programming occurs using the requirements
and design as a guideline.
• Testing: Try out the app looking for errors and confirming that documented
requirements are met.
• Implementation: Making the app available for people to use.
• Support: Monitor user experience. Sometimes recommendations for revisions arise.
If those recommendations are pursued, they will go through the lifecycle also.

2 | P a g e



Although the steps that should be taken in application design are always the same, the
methods used to execute them can be different. Each methodology must provide a solution
for the seven stages of the SDLC.The three most common types of application development
methodologies are: waterfall development, agile development and Rapid Application
Development (RAD).

3.3 APPLICATION DEVELOPMENT METHODOLOGIES
Application development methodology refers to the process of planning, creating, testing
and then deploying a project. Most application development methodologies can be grouped
into one of three categories:

• Waterfall
• RAD
• Agile

3.3.1 WATER FALL

The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. The waterfall Model illustrates the software
development process in a linear sequential flow. This means that any phase in the
development process begins only if the previous phase is complete. In this waterfall model,
the phases do not overlap, the outcome of one phase acts as the input for the next phase
sequentially
The key words for the waterfall method of application development are planning and
sequence. The entire project is mapped out in the planning and analysis stages. The
customer comes with a very explicit list of features and functionalities for the application.
Then, a project manager takes the whole process and maps it out amongst the team.
This application development method is called waterfall because once you go down, you
can’t go back up; everything flows downward. The development team works together over a
set of time, building exactly what is lined out according to the specifications. After the
architecture is designed, then only can the construction begin. The entire application is
built, and then it is all tested to make sure that it is working properly. Then, it is shown to
the customer and ready to be implemented.

3 | P a g e



The sequential phases in Waterfall model are −
• Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement
specification document.
• System Design − the requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
• Implementation − with inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system
is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To
fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the customer
environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model, phases do not overlap.

3.3.1.1 Advantages

• Simple and easy to understand and use

• Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

3.3.1.2 Disadvantage :

The major disadvantages of the Waterfall Model are as follows −

• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.

4 | P a g e



• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying
any technological or business bottleneck or challenges early.

3.3.2 RAPID APPLICATION DEVELOPMENT (RAD)

As you might imagine, the waterfall method of application development presented some big
problems. The development process often took a long time to see a working product, teams
had to be large to accommodate all the requirements, and tensions ran high when a
customer is unhappy with the end product and the whole project has to start over from the
beginning.
So, a new method emerged called rapid application development (RAD). In many
ways, RAD was the opposite of the waterfall method.
RAD is based mostly on prototypes, meaning that the goal is to produce a working version of
the application as quickly as possible, and then to continuously iterate after that. The
application development team and the customer work very closely with each other
throughout the process. RAD teams are usually small and only involve experienced
developers who are skilled in many disciplines. If a project needs to divert from the original
plan, RAD should be able to accommodate that easily.

In the RAD model, as each iteration is completed, the product gets more and more refined.
The early prototypes are often very rough, but give a picture of what can be. Each iteration
then looks more like the finished product.

Fig 3

5 | P a g e



3.3.2.1Steps in Rapid Application Development

Although RAD has changed over the years, these four basic steps provide some continuity
over the years.

1. Define the requirements

2. Prototype
3. Receive Feedback
4. Finalize Software

ADVANTAGES OF RAD DISADVANTAGES OF RAD

Requirements can be changed at any time Needs strong team collaboration
Encourages and priorities customer feedback Cannot work with large teams
Reviews are quick Needs highly skilled developers
Development time is drastically reduced Needs user requirement throughout the life
cycle of the product
More productivity with fewer people Only suitable for projects which have a small
development time
Time between prototypes and iterations is short More complex to manage when compared to
other models
Integration isn’t a problem, since it integrates from Only systems which can be
project inception

RAD Model - Application
• RAD model can be applied successfully to the projects in which clear modularization
is possible. If the project cannot be broken into modules, RAD may fail.
• RAD should be used only when a system can be modularized to be delivered in an
incremental manner.
• It should be used if there is a high availability of designers for Modelling.
• It should be used only if the budget permits use of automated code generating tools.
• RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge.
Should be used where the requirements change during the project and working prototypes
are to be presented to customer in small iterations of 2-3 months.

3.3.3 AGILE
Agile application development is very similar to RAD, but also includes some changes to
make it more suitable to larger projects. Agile is iterative, like RAD, but focuses on building
features one at a time. Each feature is built in a methodical way in the team, but the
customer is involved to see the features and sign off on them before the next feature is
developed.

6 | P a g e



Agile uses sprints, or set of time when a certain feature should be built, tested, and
presented. It tries to incorporate the entire SDLC for a feature into each sprint. This, ideally,
helps to stick to a planned schedule, but also allow for frequent reviews.

Agile doesn’t focus on prototypes, but only presents completed work after the sprint is over.
So while the customer is informed more often than waterfall, the customer only ever sees
finished work, unlike RAD.

With Agile, the application development team will also include testers, UX designers,
technical writers, and many others. Agile is based on the adaptive software development
methods, whereas the traditional SDLC models like the waterfall model is based on a
predictive approach.

FIG 4

3.3.3.1 The advantages of the Agile Model are as follows −
• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.

7 | P a g e



3.3.3.2 The disadvantages of the Agile Model are as follows −
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must without which it will
not work.
• Strict delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can be
driven in the wrong direction.
• There is a very high individual dependency, since there is minimum documentation
generated.
• Transfer of technology to new team members may be quite challenging due to lack
of documentation.

4.0 SOFTWARE VISUALIZATION

Software visualization is the practice of creating visual tools to map software elements or
otherwise display aspects of source code. This can be done with all kinds of programming
languages in different ways with different criteria and tools.
The fundamental idea behind software visualization is that by creating visual interfaces,
creators can help developers and others to understand code or to reverse-engineer
applications. A lot of the power of software visualization has to do with understanding
relationships between pieces of code, where specific visual tools, such as windows, will
present this information in an accessible way. Other features may involve different kinds of
diagrams or templates that developers can use to compare existing code to a certain
standard.
Experts point out that software visualization typically uses metric data about software, as
well as the actual source code, to showcase how code works through various kinds of
mapping and presentation. Software visualization can be used for quality control in software
development or, again, to try to reverse-engineer code.

4.1 VIRSUALIZATION TOOLS

Various tools have been built for software visualization. For instance,

4.1.1 AgileJ StructureViews helps with software visualization for Java, with
features including filtering tools for distinguishing Java elements, including classes, fields
and methods, as well as batching technology.

8 | P a g e



4.1.2 Microsoft Visual Studio. Visual Studio works with multiple programming
languages and includes a lot of software visualization functionality, as well as top-level
interface design that helps developers to build applications for Windows operating systems.
In general, Visual Studio is a visual interface to support object-oriented programming. It not
only helps individuals and teams to create applications from scratch, but it also does the
sort of things that software visualization is intended to help with; by creating Windows-
based mapping and visual design, it shows relationships between code modules as part of a
greater structural approach to coding that is inherently visual and distributed in nature

4.1.3 AXON 200 that creates flowcharts or concept diagrams to list all the influencing
factors by using visual attributes like shape, size, scale and depth. Such systems are enabled
to help users connect all related ideas using connectors, so that a graphical map of the
user’s thought process can be shared with someone else.

4.1.4 Inspiration Inc. is a visualization system that gives a blank canvas to the user in
which an individual can record and arrange ideas as per occurrence, so that he can later
connect and organize his thoughts with a visual approach.
.

5.0 PROGRAMMING PATTERN

5.1 Design Patterns
In software engineering, a design pattern is a general repeatable solution to a commonly
occurring problem in software design. A design pattern isn't a finished design that can be
transformed directly into code. It is a description or template for how to solve a problem
that can be used in many different situations.

5.1.1 Uses of Design Patterns

Ø Design patterns can speed up the development process by providing tested, proven
development paradigms. Effective software design requires considering issues that may
not become visible until later in the implementation. Reusing design patterns helps to
prevent subtle issues that can cause major problems and improves code readability for
coders and architects familiar with the patterns.
Ø Often, people only understand how to apply certain software design techniques to certain
problems. These techniques are difficult to apply to a broader range of problems. Design
patterns provide general solutions, documented in a format that doesn't require specifics tied
to a particular problem.
Ø Patterns allow developers to communicate using well-known, well understood names for
software interactions. Common design patterns can be improved over time, making them
more robust than ad-hoc designs.

9 | P a g e



5.2 Types of design patterns

5.2.1 Creational design patterns

These design patterns are all about class instantiation. This pattern can be further divided
into class-creation patterns and object-creational patterns. While class-creation patterns
use inheritance effectively in the instantiation process, object-creation patterns use
delegation effectively to get the job done.

• Abstract Factory
Creates an instance of several families of classes
• Builder
Separates object construction from its representation
• Factory Method
Creates an instance of several derived classes
• Object Pool
Avoid expensive acquisition and release of resources by recycling objects that are no
longer in use
• Prototype
A fully initialized instance to be copied or cloned
• Singleton
A class of which only a single instance can exist

5.2.1.1 Rules of thumb for creational design pattern

1. Sometimes creational patterns are competitors: there are cases when
either Prototype or Abstract Factory could be used profitably. At other times they
are complementary: Abstract Factory might store a set of Prototypes from which
to clone and return product objects, Builder can use one of the other patterns to
implement which components get built. Abstract Factory, Builder, and Prototypecan
use Singleton in their implementation.
2. Abstract Factory, Builder, and Prototype define a factory object that's responsible
for knowing and creating the class of product objects, and make it a parameter of
the system. Abstract Factory has the factory object producing objects of several
classes. Builder has the factory object building a complex product incrementally
using a correspondingly complex protocol. Prototype has the factory object (aka
prototype) building a product by copying a prototype object.
3. Abstract Factory classes are often implemented with Factory Methods, but they can
also be implemented using Prototype.
4. Abstract Factory can be used as an alternative to Facade to hide platform-specific
classes.
5. Builder focuses on constructing a complex object step by step. Abstract
Factoryemphasizes a family of product objects (either simple or
complex). Builder returns the product as a final step, but as far as the Abstract
Factory is concerned, the product gets returned immediately.
6. Builder is to creation as Strategy is to algorithm.

10 | P a g e



7. Builder often builds a Composite.
8. Factory Methods are usually called within Template methods.
9. Factory Method: creation through inheritance. Prototype: creation through
delegation.
10. Often, designs start out using Factory Method (less complicated, more customizable,
subclasses proliferate) and evolve toward Abstract Factory, Prototype,
or Builder (more flexible, more complex) as the designer discovers where more
flexibility is needed.
11. Prototype doesn't require subclassing, but it does require an Initialize
operation. Factory Method requires subclassing, but doesn't require Initialize.
12. Designs that make heavy use of the Composite and Decorator patterns often can
benefit from Prototype as well.

5.2.2 Structural design patterns

These design patterns are all about Class and Object composition. Structural class-creation
patterns use inheritance to compose interfaces. Structural object-patterns define ways to
compose objects to obtain new functionality.

• Adapter
Match interfaces of different classes
• Bridge
Separates an object’s interface from its implementation
• Composite
A tree structure of simple and composite objects
• Decorator
Add responsibilities to objects dynamically
• Facade
A single class that represents an entire subsystem
• Flyweight
A fine-grained instance used for efficient sharing
• Private Class Data
Restricts accessor/mutator access
• Proxy
An object representing another object

11 | P a g e



5.2.2.1 Rules of thumb
1. Adapter makes things work after they're designed; Bridge makes them work before
they are.
2. Bridge is designed up-front to let the abstraction and the implementation vary
independently. Adapter is retrofitted to make unrelated classes work together.
3. Adapter provides a different interface to its subject. Proxy provides the same
interface. Decorator provides an enhanced interface.
4. Adapter changes an object's interface, Decorator enhances an object's
responsibilities. Decorator is thus more transparent to the client. As a
consequence, Decorator supports recursive composition, which isn't possible with
pure Adapters.
5. Composite and Decorator have similar structure diagrams, reflecting the fact that
both rely on recursive composition to organize an open-ended number of objects.
6. Composite can be traversed with Iterator. Visitor can apply an operation over
a Composite. Composite could use Chain of responsibility to let components access
global properties through their parent. It could also use Decorator to override these
properties on parts of the composition. It could use Observer to tie one object
structure to another and State to let a component change its behavior as its state
changes.
7. Composite can let you compose a Mediator out of smaller pieces through recursive
composition.
8. Decorator lets you change the skin of an object. Strategy lets you change the guts.
9. Decorator is designed to let you add responsibilities to objects without
subclassing. Composite's focus is not on embellishment but on representation.
These intents are distinct but complementary.
Consequently, Composite and Decorator are often used in concert.
10. Decorator and Proxy have different purposes but similar structures. Both describe
how to provide a level of indirection to another object, and the implementations
keep a reference to the object to which they forward requests.
11. Facade defines a new interface, whereas Adapter reuses an old interface.
Remember that Adapter makes two existing interfaces work together as opposed to
defining an entirely new one.
12. Facade objects are often Singleton because only one Facade object is required.
13. Mediator is similar to Facade in that it abstracts functionality of existing
classes. Mediator abstracts/centralizes arbitrary communication between colleague
objects, it routinely "adds value", and it is known/referenced by the colleague
objects. In contrast, Facade defines a simpler interface to a subsystem, it doesn't add
new functionality, and it is not known by the subsystem classes.
14. Abstract Factory can be used as an alternative to Facade to hide platform-specific
classes.
15. Whereas Flyweight shows how to make lots of little objects, Facade shows how to
make a single object represent an entire subsystem.
16. Flyweight is often combined with Composite to implement shared leaf nodes.
17. Flyweight explains when and how State objects can be shared.

12 | P a g e



5.2.3 Behavioral design patterns
These design patterns are all about Class's objects communication. Behavioral patterns are
those patterns that are most specifically concerned with communication between objects.

• Chain of responsibility
A way of passing a request between a chain of objects
• Command
Encapsulate a command request as an object
• Interpreter
A way to include language elements in a program
• Iterator
Sequentially access the elements of a collection
• Mediator
Defines simplified communication between classes
• Memento
Capture and restore an object's internal state
• Null Object
Designed to act as a default value of an object
• Observer
A way of notifying change to a number of classes
• State
Alter an object's behavior when its state changes
• Strategy
Encapsulates an algorithm inside a class
• Template method
Defer the exact steps of an algorithm to a subclass
• Visitor
Defines a new operation to a class without change

5.3.3.1Rules of thumb
1. Behavioral patterns are concerned with the assignment of responsibilities between
objects, or, encapsulating behavior in an object and delegating requests to it.
2. Chain of responsibility, Command, Mediator, and Observer, address how you can
decouple senders and receivers, but with different trade-offs. Chain of
responsibility passes a sender request along a chain of potential
receivers. Command normally specifies a sender-receiver connection with a
subclass. Mediator has senders and receivers reference each other
indirectly. Observer defines a very decoupled interface that allows for multiple
receivers to be configured at run-time.
3. Chain of responsibility can use Command to represent requests as objects.
4. Chain of responsibility is often applied in conjunction with Composite. There, a
component's parent can act as its successor.
5. Command and Memento act as magic tokens to be passed around and invoked at a
later time. In Command, the token represents a request; in Memento, it represents
the internal state of an object at a particular time. Polymorphism is important

13 | P a g e



to Command, but not to Memento because its interface is so narrow that a
memento can only be passed as a value.
6. Command can use Memento to maintain the state required for an undo operation.
7. Macro Commands can be implemented with Composite.
8. A Command that must be copied before being placed on a history list acts as
a Prototype.
9. Interpreter can use State to define parsing contexts.
10. The abstract syntax tree of Interpreter is
a Composite (therefore Iterator and Visitor are also applicable).
11. Terminal symbols within Interpreter's abstract syntax tree can be shared
with Flyweight.
12. Iterator can traverse a Composite. Visitor can apply an operation over a Composite.
13. Polymorphic Iterators rely on Factory Methods to instantiate the
appropriate Iterator subclass.
14. Mediator and Observer are competing patterns. The difference between them is
that Observer distributes communication by introducing "observer" and "subject"
objects, whereas a Mediator object encapsulates the communication between other
objects. We've found it easier to make reusable Observers and Subjects than to
make reusable Mediators.
15. On the other hand, Mediator can leverage Observer for dynamically registering
colleagues and communicating with them.
16. Mediator is similar to Facade in that it abstracts functionality of existing
classes. Mediator abstracts/centralizes arbitrary communication between colleague
objects, it routinely "adds value", and it is known/referenced by the colleague
objects (i.e. it defines a multidirectional.

6.0 CRITICISM OF PROGRAM PATTERN

The concept of design patterns has been criticized by some in the field of computer science.

6.1 Targets the wrong problem

The need for patterns results from using computer languages or techniques with insufficient
abstraction ability. Under ideal factoring, a concept should not be copied, but merely
referenced. But if something is referenced instead of copied, then there is no "pattern" to
label and catalog. Paul Graham writes in the essay Revenge of the Nerds.

Peter Norvig provides a similar argument. He demonstrates that 16 out of the 23 patterns in
the Design Patterns book (which is primarily focused on C++) are simplified or eliminated
(via direct language support) in Lisp or Dylan.

6.2 Lacks formal foundations

The study of design patterns has been excessively ad hoc, and some have argued that the
concept sorely needs to be put on a more formal footing. At OOPSLA 1999, the Gang of Four
were (with their full cooperation) subjected to a show trial, in which they were "charged"
with numerous crimes against computer science. They were "convicted" by ⅔ of the "jurors"
who attended the trial.

14 | P a g e



6.3 Leads to inefficient solutions
The idea of a design pattern is an attempt to standardize what are already accepted best
practices. In principle this might appear to be beneficial, but in practice it often results in
the unnecessary duplication of code. It is almost always a more efficient solution to use a
well-factored implementation rather than a "just barely good enough" design pattern.

6.4 Does not differ significantly from other abstractions

Some authors allege that design patterns don't differ significantly from other forms of
abstraction, and that the use of new terminology (borrowed from the architecture
community) to describe existing phenomena in the field of programming is unnecessary.
The Model-View-Controller paradigm is touted as an example of a "pattern" which predates
the concept of "design patterns" by several years. It is further argued by some that the
primary contribution of the Design Patterns community (and the Gang of Four book)
was the use of Alexander's pattern language as a form of documentation; a practice
which is often ignored in the literature.

15 | P a g e