Enterprise: An organizational unit which ranges from a department to whole corporation.
An Enterprise Architecture is a conceptual blueprint that defines the structure and operations of organization. The intent of enterprise architecture is to determine how an organization can effectively achieve its current and future objectives. Enterprise architecture involves practice of analyzing, planning, designing and eventual implementing of analysis of an enterprise.
Enterprise Architecture is about understanding all the different components that go to make up the enterprise and how those components are inter-relate.
Layers of Enterprise Architecture
Enterprise Application
An enterprise application is the phrase used to describe applications(or software) that a business would use to assist the organization in solving enterprise problems. When the word “enterprise” is combined with “application,” it usually refers to a software platform that is too large and too complex for individual or small business use.
Example of Enterprise Applications
- Automated Billing Systems
- Online Content Management
- Email Marketing System
- HR Management
- Customer Relationship Management
Java is widely used for developing EA.
Java is one of the most robust programming language used for developing small applications to large end-to-end enterprise software. Java has a vast array of excellent libraries for solving most of the common problems one needs to solve when developing enterprise application. For example Spring Boot, Quarkus, Apache Spark, Apache Flink etc.
Many companies choose Java for developing EA because:
1. Shorter Learning Curve
Java is a simple language with a huge support base. Enterprise projects tend to involve large number of developers and it is much easier to get a developer to a minimum level of competence in a Java than other language like C++. A lot of university graduate have been largely schooled in Java.
2. Java Supports a vast arrays of libraries
Java has a vast array of excellent libraries for solving most of the common problems one needs to solve when developing enterprise application. For example Spring Boot, Quarkus, Apache Spark, Apache Flink etc.
3. Platform Independence
Java is writing once, run everywhere. Sun has actively encouraged open standards that allow multiple vendors to implement their solutions. These standards give the customer the comfort that they can migrate from one vendor to another if a given vendor goes under or starts charging more.
4. Easy integration and scalability
Being supported by a huge user community, Java is a very handy tool for web development. Many of the hosting providers support Java code for hosting their web applications. Hadoop, the big name in Data is written in Java. Java is also highly scalable, making it easy for enterprise to ramp-up their application development needs as per the demand.
5. Intertia
Large corporation update themselves very slow, so once they have picked up Java, it takes a huge investment to migrate to another platform. And convincing for change is to assure them to invest a lot of money for no immediate business benefit.
6. Use of OOPs concents.
7. Secure
Enterprise Architecture Framework (EA Framework)
EA framework defines how to create and use an enterprise architecture. It is a structure for the content of an Enterprise Architecture Description, according to IEEE 1471 definition, we can describe an EA Framework as the model shown below:
Frameworks help people organize and assess completeness of integrated models of their
enterprises. An Architectural Framework gives a skeletal structure that defines suggested
architectural artifacts, describes how those artifacts are related to each other, and provides
generic definitions for what those artifacts might look like. EAF says:
→ How to create and use an enterprise architecture.
→ Principles and practices for creating and using architectural description of the system.
Types of EA Framework
The industry standard EA framework includes three different types of frameworks:
1. Template Framework
– Zachman Framework
2. Content Framework
– The Open Group Architecture Framework(TOGAF)
– The Department of Defense Architecture Framework(DODAF)
3. Unified Profile for EA Framework from OMG
1. Zachman Enterprise Application Framework
The framework is named after its creator John Zachman, who first developed the concept in the 1980s at IBM. It has been updated ever since.
Zachman Framework is an enterprise ontology which provides formal and highly structured way of viewing and defining and enterprise. It consists of two-dimensional 6x6 classification matrix based on the intersection of six communication questions (What, Where, When, Why Who and How) with five levels of reification, successively transforming the most abstract ideas(on the scope level) into more concrete ideas(at the operations level).
The rows present:
- Different perspectives of the enterprise
- Different Views of the enterprise
- Different roles in the enterprise
1. Scope describes the system’s vision, mission, boundaries, architecture and constraints. The scope states what the system is to do. It is called a black box model, because we see the inputs and outputs, but not the inner workings.
2. Business model shows goals, strategies and processes that are used to support the mission of the organization.
3. System model contains system requirements, objectives, activities and functions that implement the business model. The system model states how the business is to perform its functions. It is called a white box model, because we see its inner workings.
4. Technology model considers the constraints of humans, tools, technology and materials.
5. Detailed representation presents individual, independent components that can be allocated to contractors for implementation.
6. Real system depicts the operational system under consideration.
Column presents:
1. What (data) describes the entities involved in each perspective of the enterprise. Examples include equipment, business objectives and system data.
2. How (functions) shows the functions within each perspective.
3. Where(networks) shows locations and interconnections within the enterprise.
4. Who (people) represent the people within the enterprise and metrics for assesing their capabilities and performance.
5. When (time) represents time, or the event relationships that establish performance criteria.
6. Why (motivation) describes the motivations of the enterprise.
2. The Open Group Architectural Framework (TOGAF)
The TOGAF was first developed in 1995. Created and owned by the The Open Group. This is one of the most common framework that accounts for over 80% of the enterprise business framework structure.
Core Concepts
1. Business Architecture - The business strategy, governance, organization, and key business processes.
2. Data Architecture - The structure of an organization's logical and physical data assets and data management resources.
3. Application Architecture - A blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
4. Architecture Technology Architecture - The logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
Note That: Information Systems Architecture = Data Architecture + Application
3. Government Enterprise Architecture Frameworks (GEAF)
Government Enterprise Architecture is define as: a whole of government approach to support government ecosystems by transcending boundaries for delivering services in a coordinated, efficient, and equitable manner.
A government business enterprise (or GBE) is a hybrid organization that has features of a private company and a public organization:
• They act like private companies in that they seek to make a profit and compete against other companies
• They act like a public organization in that they carry out government policies and non-commercial services; think of the mail service, railways, etc.
Objectives
1. Transformation for e-Government.
2. Managing stakeholders in complex government environment.
3. Measuring and demonstrating success.
4. Managing procurement, budgeting, and public expenditures.
5. Share information, knowledge, technology and other resources.
6. Optimize ICT investment and business cases across the whole government.
In the context of government enterprises: a coordinated set of activity areas involving one or more public organizations and possibly third-party entities from private organizations or civil society, an EA provides technical descriptions of the organizational goals, business and
administrative processes, information requirements, supporting applications and technology
infrastructure of the enterprise. These descriptions are typically captured in the form of
models, diagrams, narratives, etc.
A Government Enterprise Architecture (GEA) may be associated with a single agency or span functional areas transcending several organizational boundaries, e.g. health care, financial management and social welfare.
Reasons for developing enterprise architectures in government include:
1. Understanding, clarifying and optimizing the inter-dependencies and relationships
among business operations, the underlying IT infrastructure and applications that support
these operations in government agencies and in the context of specific government
enterprises
2. Establishing a basis for agencies to share information, knowledge and technology and
other resources or jointly participate in the execution of business processes
3. Optimizing ICT investment and business cases across the whole of government by
enabling the opportunities for collaboration and sharing of assets, thus reducing the
tendency for duplicated and poorly integrated IT resources and capabilities
There is increasing awareness on the importance of EA as most of the leading countries in e-
government have well established EA programs. Presently, there are EA maturity models with
defined relations to well known e-Government Maturity stages. The increasing popularity of
EA practices by governments in both developed and developing countries is indicated by the
different global surveys on EA.
Java Enterprise Edition
The Java EE platform is designed to help developers create large-scale, multi-tiered, scalable, reliable, and secure network applications. A shorthand name for such applications is "enterprise applications," so called because these applications are designed to solve the problems encountered by large enterprises.
The features that make enterprise applications powerful, like security and reliability, often make these applications complex. The Java EE platform reduces the complexity of enterprise application development by providing a development model, API, and runtime environment that allow developers to concentrate on functionality.
Tiered Applications
In a multi-tiered application, the functionality of the application is separated into isolated functional areas, called tiers. Typically, multi-tiered applications have a client tier, a middle tier, and a data tier (often called the enterprise information systems tier). The client tier consists of a client program that makes requests to the middle tier. The middle tier is divided into a web tier and a business tier, which handle client requests and process application data, storing it in a permanent datastore in the data tier.
1. The Client Tier
2. The Middle Tier
- Web Tier(JavaServer Faces Technology, Expression Language, Servlets, Contexts and Dependency Injection for Java EE)
- Business Tier (Enterprise JavaBeans Components, JAX-RS RESTful web services, Java Persistence API)
3. Data Tier or Enterprise Information System Tier (JDBC API, JTA API, Java EE Connector Architecture)
The 13 core technologies that make up Java EE are:
1. JDBC : JDBC stands for Java Database Connectivity, which is a standard Java API for database-independent connectivity between the Java programming language and a wide range of databases.
2. JNDI : JNDI stands for Java Naming and Directory Interface. JNDI allows distributed applications to look up services in an abstract, resource-independent way. The most common use case is to set up a database connection pool on a Java EE application server.
3. EJBs: EJB stands for Enterprise Java Beans. EJB is a server-side software component that encapsulates business logic of an application. The EJB specifications provides a standard way to implement the server-side (also called “back-end”).
4. JSP: JavaServer Pages (JSP) is a Java standard technology that enables you to write dynamic, data-driven pages for your Java web applications. JSP is built on top of the Java Servlet Specification.
5. Java Servlets: A servlet is simply a class which responds to a particular type of network request - most commonly an HTTP request. Basically servlets are usually used to implement web applications.
6. Java Mail: The JavaMail is an API that is used to compose, write and read electronic messages (emails).The JavaMail API provides protocol-independent and plateform-independent framework for sending and receiving mails.
7. RMI
8. XML
9. JMS
10. Java IDL
11. JTS
12. JTA (Java Transaction API)
13. JAF (Java Activation Framework)
Java Frameworks
Spring, Hibernate, Struts, JavaServer Faces (JSF), Google Web Kit (GWT), Play, Grails, Vert.X, Apache Wicket,
Internet Based Communications
→ Instant Messaging
→ Internet Technology and VoIP
→ E-mail
→ Internet Relay Chat
→ Video Conferencing
→ SMS
Protocols
Protocols exist at several levels in a telecommunication connection. For example, there are
protocols for the data interchange at the hardware device level and protocols for data interchange
at the application program level.
Some of the important protocols of internet are:
Transmission Control Protocol (TCP) is a connection-oriented protocol that provides reliable,ordered, error-checked delivery of packets.
Internet Protocol (IP) has the task of delivering packets from the source host to the destination host solely based on the IP addresses in the packet headers.
User Datagram Protocol (UDP) is a connection-less protocol that does not provide reliability, order or error-checking. UDP messages are referred to as datagrams and a datagram is defined as a basic transfer unit associated with a packet-switched network in which the delivery, arrival time, and order of arrival are not guaranteed by the network.
Hypertext Transfer Protocol (HTTP) is the protocol to exchange or transfer hypertext. Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. HTTP is called as a stateless protocol because each request is executed independently, without any knowledge of the requests that were executed before it, which means once the transaction ends the connection between the browser and the server is also lost.
HTTP is a textual, stateless protocol.
Textual
All commands are plain-text and human-readable.
Stateless
Neither the server nor the client remember previous communications. For example, relying on HTTP alone, a server can't remember a password you typed or remember your progress on an incomplete transaction. You need an application server for tasks like that.
The World Wide Web (abbreviated as WWW or W3) or the web is a system of interlinked hypertext documents accessed via the Internet. With a web browser, one can view web pages and navigate between them via hyperlinks.
FTP is a standard network protocol used to transfer files from one host to another host over a TCP-based network.
SMTP is an Internet standard for electronic mail (e-mail) transmission across Internet Protocol (IP) networks.
Enterprise JavaBeans
EJB is one of several Java APIs for modular construction of enterprise software. EJB is a server-side software component that encapsulates business logic of an application. The EJB specifications provides a standard way to implement the server-side (also called “back-end”). EJB is intended to handle such common concerns as persistence, transactional integrity and security in a standard way, leaving programmers free to concentrate on particular parts of the enterprise software ant hand.
Responsibilities
→ Transaction Processing
→ Concurrency Control
→ Job Scheduling
→ Event Driven Programming
→ Security
→ Deployment of software components in an application server
→ IPC using RMI-IIOP and Web Services
→ Asynchronous Method Invocation
The following shows a basic example of what an EJB looks like in code:
@Stateless
public class CustomerService {
private EntityManager entityManager;
public void addCustomer(Customer customer) {
entityManager.persist(customer);
}
}
The above defines a service class for persisting a Customer object (via O/R mapping). The EJB takes care of managing the persistence context and the addCustomer() method is transactional and thread-safe by default. As demonstrated, the EJB focuses only on business logic and persistence and knows nothing about any particular presentation.
Types of Enterprise Beans
1. Sessions Beans that can be either “Statefull”, “Stateless” or “Singleton”
Session bean contains business logic that can be invoked by local, remote or webservice client.
2. Message Driven Beans (MDB)
Like session bean, it can contains the business logic but is invoked by message passing.
3. Entity Bean
It encapsulates the state that can be persisted in database. It is deprecated an is now replaced by JPA.
Type
Description
Session Bean
Session bean stores data of a particular user for a single session.
It can be stateful or stateless. It is less resource intensive as compared to entity beans. Session bean gets destroyed as soon as user session terminates.
Entity Bean
Entity beans represents persistent data storage.
User data can be saved to database via entity beans and later on can be
retrieved from the database in the entity bean.
Message Driven Bean
Message driven beans are used in context of
JMS (Java Messaging Service). Message Driven Beans can
consumes JMS messages from external entities and act accordingly.
Disadvantage of EJB
→ Requires application server.
→ Requires only java client.
→ Complex to understand.
→ Complex to develop EJB applications.
Web Services
A web service enables communication among various applications by using open standards such as HTML, XML, WSDL, and SOAP. A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards.
Components of Web Services
The basic web services platform is XML + HTTP. All the standard web services work using the following components −
• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)
How Does a Web Service Work?
A web service enables communication among various applications by using open standards such as HTML, XML, WSDL, and SOAP. A web service takes the help of −
• XML to tag the data
• SOAP to transfer a message
• WSDL to describe the availability of service.
You can build a Java-based web service on Solaris that is accessible from your Visual Basic program that runs on Windows. You can also use C# to build new web services on Windows that can be invoked from your web application that is based on JavaServer Pages (JSP) and runs on Linux.
Importance of Web Services
Exposing the Existing Function on the network
A web service is a unit of managed code that can be remotely invoked using HTTP. That is, it can be activated using HTTP requests. Web services allow you to expose the functionality of your existing code over the network. Once it is exposed on the network, other applications can use the functionality of your program.
Interoperability
Web services allow various applications to talk to each other and share data and services among themselves. Other applications can also use the web services. For example, a VB or .NET application can talk to Java web services and vice versa. Web services are used to make the application platform and technology independent.
Standardized Protocol
Web services use standardized industry standard protocol for the communication. All the four layers (Service Transport, XML Messaging, Service Description, and Service Discovery layers) use well-defined protocols in the web services protocol stack. This standardization of protocol stack gives the business many advantages such as a wide range of choices, reduction in the cost due to competition, and increase in the quality.
Low Cost Communication
Web services use SOAP over HTTP protocol, so you can use your existing low-cost internet for implementing web services. This solution is much less costly compared to proprietary solutions like EDI/B2B. Besides SOAP over HTTP, web services can also be implemented on other reliable transport mechanisms like FTP.
Service Oriented Architecture
SOA, or service-oriented architecture, defines a way to make software components reusable via service interfaces. These interfaces utilize common communication standards in such a way that they can be rapidly incorporated into new applications without having to perform deep integration each time.
There are several types of services used in SOA systems.
Business services
Entity services
Functional services
Utility services
Benefits
Ability to build business applications faster and more easily
Easier maintenance / update
Business agility and extensibility
Lower total cost of ownership
Greater business agility; faster time to market: The efficiency of assembling applications from reusable service interfaces, rather than rewriting and reintegrating with every new development project, enables developers to build applications much more quickly in response to new business opportunities.
Ability to leverage legacy functionality in new markets: A well-crafted SOA enables developers to easily take functionality ‘locked’ in one computing platform or environment and extend it to new environments and markets. For example, many companies have used SOA to expose functionality from mainframe-based financial systems to the web, enabling their customers to serve themselves to processes and information previously accessible only through direct interaction with the company’s employees or business partners.
Improved collaboration between business and IT: In an SOA, services can be defined in business terms (e.g., ‘generate insurance quote’ or ‘calculate capital equipment ROI’). This enables business analysts to work more effectively with developers on important insights—such as the scope of a business process defined by a service or the business implications of changing a process—that can lead to a better result.
Data Exchange is the process of taking data structured under a source schema and transforming it into data structured under a target schema, so that the target data is an accurate representation of the source data.
Data exchange format is an interim data format for converting from one file or database structure to another. Also called a “data exchange format”. The source data is converted into the exchange format by one program, and the data in the exchange format is converted to the target format by another program. XML is commonly used as a data exchange format.
Extensible Markup Language (XML)
XML is a markup language that defines a set of rule for encoding documents in a format that is both human-readable and machine-readable.
XML Tree Structure
XML documents are formed as element trees.
An XML tree starts at a root element and branches from the root to child elements.
All elements can have sub elements (child elements):
<root>
<child>
<subchild>.....</subchild>
</child>
</root>
The terms parent, child, and sibling are used to describe the relationships between elements.
Parents have children. Children have parents. Siblings are children on the same level (brothers and sisters). All elements can have text content (Harry Potter) and attributes (category="cooking").
Self-Describing Syntax
XML uses a much self-describing syntax.
A prolog defines the XML version and the character encoding:
<?xml version="1.0" encoding="UTF-8"?>
The next line is the root element of the document:
<bookstore>
The next line starts a <book> element:
<book category="cooking">
The <book> elements have 4 child elements: <title>, <author>, <year>, <price>.
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
<price>30.00</price>
The next line ends the book element:
</book>
You can assume, from this example, that the XML document contains information about books in a bookstore.
XML Terminology
XML Binding in Java
Java Architecture for XML Binding (JAXB) provides a fast and convenient way to bind XML schemas and Java representations, making it easy for Java developers to incorporate XML data and processing functions in Java applications. As part of this process, JAXB provides methods for unmarshalling (reading) XML instance documents into Java content trees, and then marshalling (writing) Java content trees back into XML instance documents. JAXB also provides a way to generate XML schema from Java objects.
The JAXB Binding Process
The following figure shows what occurs during the JAXB binding process.
Figure: Steps in the JAXB Binding Process
The general steps in the JAXB data binding process are:
1. Generate classes: An XML schema is used as input to the JAXB binding compiler to generate JAXB classes based on that schema.
2. Compile classes: All of the generated classes, source files, and application code must be compiled.
3. Unmarshal: XML documents written according to the constraints in the source schema are unmarshalled by the JAXB binding framework. Note that JAXB also supports unmarshalling XML data from sources other than files and documents, such as DOM nodes, string buffers, SAX sources, and so forth.
4. Generate content tree: The unmarshalling process generates a content tree of data objects instantiated from the generated JAXB classes; this content tree represents the structure and content of the source XML documents.
5. Validate (optional): The unmarshalling process involves validation of the source XML documents before generating the content tree. Note that if you modify the content tree in Step 6, you can also use the JAXB Validate operation to validate the changes before marshalling the content back to an XML document.
6. Process content: The client application can modify the XML data represented by the Java content tree by using interfaces generated by the binding compiler.
7. Marshal: The processed content tree is marshalled out to one or more XML output documents. The content may be validated before marshalling.
More About Unmarshalling
Unmarshalling provides a client application the ability to convert XML data into JAXB-derived Java objects.
More About Marshalling
Marshalling provides a client application the ability to convert a JAXB-derived Java object tree into XML data.
By default, the Marshaller uses UTF-8 encoding when generating XML data.
JSON
JSON is Like XML Because
• Both JSON and XML are "self describing" (human readable)
• Both JSON and XML are hierarchical (values within values)
• Both JSON and XML can be parsed and used by lots of programming languages
• Both JSON and XML can be fetched with an XMLHttpRequest
JSON is Unlike XML Because
• JSON doesn't use end tag
• JSON is shorter
• JSON is quicker to read and write
• JSON can use arrays
The biggest difference is: XML has to be parsed with an XML parser. JSON can be parsed by a standard JavaScript function.
Why JSON is Better Than XML
XML is much more difficult to parse than JSON.
JSON is parsed into a ready-to-use JavaScript object.
For AJAX applications, JSON is faster and easier than XML:
Using XML
• Fetch an XML document
• Use the XML DOM to loop through the document
• Extract values and store in variables
Using JSON
• Fetch a JSON string
• JSON.Parse the JSON string
Resource Description Framework (RDF)
SOAP
WSDL
UDDI(Universal Description, Discovery and Integration)
ebXML
1. Document Type Definition (DTD) :
DTD stands for Document Type Definition and it is a document which defines the structure of an XML document. It is used to describe the attributes of XML language precisely. It can be classified into two types namely internal DTD and external DTD. It can be specified inside a document or outside a document. DTD mainly checks the grammar and validity of a XML document. It checks that a XML document has a valid structure or not.
2. XML Schema Definition (XSD) :
XSD stands for XML Schema Definition and it is a way to describe the structure of a XML document. It defines the rules for all the attributes and elements in a XML document. It can also be used to generate the XML documents. It also checks the vocabulary of the document. It doesn’t require processing by a parser. XSD checks for the correctness of the structure of the XML file. XSD was first published in 2001 and after that it was published in 2004.
Difference between Document Type Definition (DTD) and XML Schema Definition (XSD) :
S.NO.
DTD
XSD
1.
DTD are the declarations that define a document type for SGML.
XSD describes the elements in a XML document.
2.
It doesn’t support namespace.
It supports namespace.
3.
It is comparatively harder than XSD.
It is relatively more simpler than DTD.
4.
It doesn’t support datatypes.
It supports datatypes.
5.
SGML syntax is used for DTD.
XML is used for writing XSD.
6.
It is not extensible in nature.
It is extensible in nature.
7.
It doesn’t give us much control on structure of XML document.
It gives us more control on structure of XML document.
Source Code Management
A version control system serves the following purposes, among others.
• Version control enables multiple people to simultaneously work on a single project. Each person edits his or her own copy of the files and chooses when to share those changes with the rest of the team. Thus, temporary or partial edits by one person do not interfere with another person's work.
• Version control integrates work done simultaneously by different team members. In most cases, edits to different files or even the same file can be combined without losing any work. In rare cases, when two people make conflicting edits to the same line of a file, then the version control system requests human assistance in deciding what to do.
• Version control gives access to historical versions of your project. This is insurance against computer crashes or data lossage. If you make a mistake, you can roll back to a previous version. You can reproduce and understand a bug report on a past version of your software. You can also undo specific edits without losing all the work that was done in the meanwhile. For any part of a file, you can determine when, why, and by whom it was ever edited.
Importance
Collaboration
Avoid Conflicting Changes
Manages Conflict
Backup and Restore – Files can be saved at any moment and can be restored from the last saved.
Synchronization – Programmers can get the latest code and fetch the up-to-date codes from the repository.
Short-Term Undo – Working with a file and messed it up. We can do a short-term undo to the last known version.
Long-Term Undo – It helps when we have to make a release version rollback. Something like going to the last version which was created a year
Track Changes – We can track the changes as when anyone is making any change, he can leave a commit message as for why the change was done.
Ownership – With every commit made to the master branch, it will ask the owner permission to merge it.
Branching and Merging – You can create a branch of your source code and create the changes. Once the changes are approved, you can merge it with the master branch.
Distributed and centralized version control
There are two general varieties of version control: centralized and distributed. Distributed version control is more modern, runs faster, is less prone to errors, has more features, and is somewhat more complex to understand. You will need to decide whether the extra complexity is worthwhile for you.
Some popular version control systems are Git (distributed), Mercurial (distributed), and Subversion (centralized).
The main difference between centralized and distributed version control is the number of repositories. In centralized version control, there is just one repository, and in distributed version control, there are multiple repositories. Here are pictures of the typical arrangements:
In centralized version control, each user gets his or her own working copy, but there is just one central repository. As soon as you commit, it is possible for your co-workers to update and to see your changes. For others to see your changes, 2 things must happen:
• You commit
• They update
In distributed version control, each user gets his or her own repository and working copy. After you commit, others have no access to your changes until you push your changes to the central repository. When you update, you do not get others' changes unless you have first pulled those changes into your repository. For others to see your changes, 4 things must happen:
• You commit
• You push
• They pull
• They update
Notice that the commit and update commands only move changes between the working copy and the local repository, without affecting any other repository. By contrast, the push and pull commands move changes between the local repository and the central repository, without affecting your working copy
The benefits of distributed version control are:
• More powerful and easy change tracking.
• No need of a centralized server. Most of the functionalities work in offline mode also apart from sharing the repositories.
• Branching and Merging strategies are more easy and reliable.
• It’s faster than the other one.
Though we have drawbacks:
• It is harder to understand.
• It’s new, so less GUI clients.
• It is easier to make mistakes until you are familiar with the model.
Version Control Tools
There are many version control tools:
1. Project Revision Control System (PRCS)
2. Source Code Control System(SCCS)
3. Revision Control System (RCS)
4. Concurrent Version System (CVS)
1. Project Revision Control System(PRCS)
The Project Revision Control System, PRCS, is the front end to a set of tools that (like CVS) provide a way to deal with sets of files and directories as an entity, preserving coherent versions of the entire set.
Abstractly, PRCS presents you ("the user") with the abstraction of named projects that have multiple (project) versions, each of which is a set of files, arranged into a directory subtree. A project is the collection of all project versions of that project. Each project version contains one distinguished file, called the (project) version descriptor, in the top directory of the subtree, which contains a description of the files included in that particular version.
Its purpose is similar to that of SCCS, RCS and CVS, but it is much simpler than any of those system.
2. Source Code Control System (SCCS)
Source Code Control System (SCCS) is a version control system designed to track changes in source code and other text files during the development of a piece of software. This allows the user to retrieve any of the previous versions of the original source code and the changes which are stored. It was originally developed at Bell Labs beginning in late 1972 by Marc Rochkind for an IBM System/370 computer running OS/360.[1]
3. Concurrent Version System (CVS)
Concurrent Versions System (CVS, also known as the Concurrent Versioning System) is a revision control system originally developed by Dick Grune in July 1986.[1]
CVS operates as a front end to RCS, an earlier system which operates on single files. It expands upon RCS by adding support for repository-level change tracking, and a client-server model.[2]
4. Revision Control Systems (RCS)
RCS was designed at the Department of Computer Science at Purdue University in 1982. RCS is a software tool for UNIX systems which lets people working on the system comtrol “multiple revisions of text … that is revised frequently, such as programs or documentation”. It can be applied to development situations of all sorts including the creation of documents, drawings, forms, articles and of course source code.
Basic Git Workflow
In general, the basic routine is:
Update your local repository with
git clone... or git pull
Edit the files locally, then
git add...
git commit...
git push...
Let’s go through the basic commands!
Always remember Git has good built in help, so add --help to any command to learn more.
git clone
To copy a repository from GitHub, use git clone. Go to your GitHub repository, click the green “Clone or download” button, and copy the URL. In your terminal, navigate to your desired location (I suggest a folder named “GitHub” in your Documents directory). Type git clone and paste in your URL (right click or shift+Ctrl+V). For example:
git clone https://github.com/uidaholib/gitworkshop.git
Clone will download a full copy of the repository to your local machine and record its origin on GitHub (if you get an error on Git Bash, check this note). This ensures there is a connection so you can push your changes to GitHub or fetch updates. Your clone has the complete history stored in the hidden .git directory.
git status
Git status is your friend. Type it often!
git status
Create a new file in your repository using a text editor, or the command line:
echo "some interesting notes" > notes.txt
Then check the status again!
git add
Once you have made changes in your repository, you need to tell Git to start tracking the file. The function git add adds the files to the “staging area”, meaning Git is now tracking the changes.
git add notes.txt
git status
git commit
We changed a file, we added it to the staging area, and now we are ready to take a snapshot storing away these changes forever! Let’s commit!
Each commit records a snapshot of the state of the full repository along with the name, timestamp, and message of the committer. A message is required! It is your note to posterity so you can remember why you made changes in the future (for style tips, see The Art of the Commit).
git commit -m "add notes file"
git status
We have stored away a new version of the documents in the repository and will be able to navigate this history. Make many smaller focused commits, rather than big ones, since small changes will be easier to undo, review, and merge.
The -m flag adds the message on the command line. If you do not include a message, Git will open your default text editor and wait for you to enter and save a message.
Repeat!
You will use add, commit, and status over and over!
Git add fills the staging area.
Git commit takes the snapshot of changes in the staging area.
Edit a file in your test repository and repeat the routine.
git add notes.txt
git commit -m "more notes"
git status
git push
Notice that git status now says “your branch is ahead of origin/master”. Origin/master is the standard way to name the main branch of the remote repository. We finished our changes to the repository locally, now we have to add them to the version hosted on GitHub using push.
git push origin master
git push
Push sends only the changes, so it is very efficient network use.
Review
git status
git pull
git add file.txt
git commit -m "message"
git push
Depending on your workflow, you may want to git fetch rather than pull. git fetch = update repository from remote. git pull = fetch + merge, i.e. update from remote and combine with local work.
CI/CD defined
Continuous integration is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. Because most modern applications require developing code in different platforms and tools, the team needs a mechanism to integrate and validate its changes.
The technical goal of CI is to establish a consistent and automated way to build, package, and test applications. With consistency in the integration process in place, teams are more likely to commit code changes more frequently, which leads to better collaboration and software quality.
Continuous delivery picks up where continuous integration ends. CD automates the delivery of applications to selected infrastructure environments. Most teams work with multiple environments other than the production, such as development and testing environments, and CD ensures there is an automated way to push code changes to them.
CI/CD tools help store the environment-specific parameters that must be packaged with each delivery. CI/CD automation then performs any necessary service calls to web servers, databases, and other services that may need to be restarted or follow other procedures when applications are deployed.
Continuous integration and continuous delivery require continuous testing because the objective is to deliver quality applications and code to users. Continuous testing is often implemented as a set of automated regression, performance, and other tests that are executed in the CI/CD pipeline.
How continuous integration improves collaboration and quality
Continuous integration is a development philosophy backed by process mechanics and some automation. When practicing CI, developers commit their code into the version control repository frequently and most teams have a minimal standard of committing code at least daily. The rationale behind this is that it’s easier to identify defects and other software quality issues on smaller code differentials rather than larger ones developed over extensive period of times. In addition, when developers work on shorter commit cycles, it is less likely for multiple developers to be editing the same code and requiring a merge when committing.
Teams implementing continuous integration often start with version control configuration and practice definitions. Even though checking in code is done frequently, features and fixes are implemented on both short and longer time frames. Development teams practicing continuous integration use different techniques to control what features and code are ready for production.
→ Frequent Commits helps to identify errors and bugs quickly.
→ Avoid merging Conflicts as there is shorter commit cycles.
Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way. We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis.
Benefits of continuous integration-continuous deployment (CI-CD)
• Smaller code changes are simpler (more atomic) and have fewer unintended consequences.
• Fault isolation is simpler and quicker.
• Mean time to resolution (MTTR) is shorter because of the smaller code changes and quicker fault isolation.
• Testability improves due to smaller, specific changes. These smaller changes allow more accurate positive and negative tests.
• Elapsed time to detect and correct production escapes is shorter with a faster rate of release.
• The backlog of non-critical defects is lower because defects are often fixed before other feature pressures arise.
• The product improves rapidly through fast feature introduction and fast turn-around on feature changes.
• Upgrades introduce smaller units of change and are less disruptive.
• CI-CD product feature velocity is high. The high velocity improves the time spent investigating and patching defects.
• Feature toggles and blue-green deploys enable seamless, targeted introduction of new production features.
• You can introduce critical changes during non-critical (regional) hours. This non-critical hour change introduction limits the potential impact of a deployment problem.
• Release cycles are shorter with targeted releases and this blocks fewer features that aren’t ready for release.
• End-user involvement and feedback during continuous development leads to usability improvements. You can add new requirements based on customer’s needs on a daily basis.
Martin Fowler
Practices of Continuous Integration
• Maintain a Single Source Repository.
• Automate the Build
• Make Your Build Self-Testing
• Everyone Commits To the Mainline Every Day
• Every Commit Should Build the Mainline on an Integration Machine
• Fix Broken Builds Immediately
• Keep the Build Fast
• Test in a Clone of the Production Environment
• Make it Easy for Anyone to Get the Latest Executable
• Everyone can see what's happening
• Automate Deployment
5 Steps to continuous integration
Concurrent Versions System (CVS) is a tool for managing collaborative software development. It enables groups of coders working on the same set of source files to coordinate and integrate the changes they make to the code, and acts as a repository to store all those changes. If, for example, two different programmers alter the same section of code, CVS can compare both versions and show that there is a difference between them (known as a “conflict” in CVS) that needs resolved or “merged.” Another feature of the system is to keep an historical record of the project’s development over time, enabling people to retrieve earlier versions. It also supports the possibility of the code “branching,” meaning that alternative versions of the same code can be split off from the main project and maintained in parallel without causing conflicts. If someone wants to experiment with re-writing a certain section of a project, they can do so in a new branch while everyone else continues to use the main branch unaffected by the experiment.
1.3.1 Getting the source
The first thing you must do is to get your own working copy of the source for ‘tc’. For this, you use the checkout command:
$ cvs checkout tc
This will create a new directory called tc and populate it with the source files.
$ cd tc
$ ls
CVS Makefile backend.c driver.c frontend.c parser.c
1.3.2 Committing your changes
When you have checked that the compiler is still compilable you decide to make a new version of backend.c. This will store your new backend.c in the repository and make it available to anyone else who is using that same repository.
$ cvs commit backend.c
1.3.3 Cleaning up
Before you turn to other tasks you decide to remove your working copy of tc.
$ cd ..
$ cvs release -d tc
M driver.c
? tc
You have [1] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': n
** `release' aborted by user choice.
The release command checks that all your modifications have been committed. If history logging is enabled it also makes a note in the history file.
1.3.4 Viewing differences
You do not remember modifying driver.c, so you want to see what has happened to that file.
$ cd tc
$ cvs diff driver.c
This command runs diff to compare the version of driver.c that you checked out with your working copy. When you see the output you remember that you added a command line option that enabled the optimization pass. You check it in, and release the module.
$ cvs commit -m "Added an optimization pass" driver.c
Checking in driver.c;
/usr/local/cvsroot/tc/driver.c,v <-- driver.c
new revision: 1.2; previous revision: 1.1
done
$ cd ..
$ cvs release -d tc
? tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': y
Some basic words or descriptions
Versions, revisions, releases
A file can have several versions; likewise, a software product can have several versions. A software product is often given a version number such as 2.2.1. Versions in the first sense are called revisions here, and the versions in the second sense are called releases. To avoid confusion, the word version is almost avoided.
Repository
The repository is the directory, which stores the master copies of the files. The main or master repository is a tree of directories.
Modules
It is a specific directory (or mini-tree of directories) in the main repository. Modules are defined in the CVS modules file.
Software testing is a process of investigation. A tester pushes your software through a great variety of tests to catch any hidden errors, unpredictable behavior, or functional inconsistencies. After every test, a tester files a detailed report that helps developers fix all the exposed issues, maintain the software error-free, and make sure it runs as intended.
1. JBehave
JBehave is an incredible and one of the best Java testing frameworks that supports BDD (Behaviour-Driven Development). BDD is an evolution of TDD (Test-Driven Development) and ATDD (Acceptance Test-Driven Development).
Behaviour-Driven Development is intended to make these practices insightful and more accessible for both beginners and specialists. It shifts the terms to behaviour-based from being test-based, and sets itself as a design paradigm, highlighting communication, and automation alike.
Features
JBehave distributions
Core distributions of Jbehave are:
• JBehave Web
• JBehave Core
Pros
JBehave BDD testing framework is also beneficial in multiple ways.
• Products have superior specifications because of the fact that this testing framework for Java features reasoning, and intuitiveness in a detailed way.
• Serves a great purpose for BDD by offering integration among distinct development teams engaged with varied projects yet similar specifics.
• JBehave framework uses a semi-formal language which is a great help for developers. Having a domain vocabulary feature aids in managing consistency in the team structure.
• Even, stakeholders, as well as project managers, get better transparency regarding the QA teams & dev team productivity as the specs have the same format.
Cons
There is only one loophole or con of JBehave just like any other BDD testing framework.
• BDD testing framework or tool success rate mostly comes down to significant communication carried out among members working in a project. It can be between the management team, the testers, the developers, and the stakeholders.
Improper communication may lead to unanswered doubts and queries. In the end this can lead to a flaw-filled app or an app not meeting up to client requirements, resulting in a blame game between all the involved parties.
What is Testing?
Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not. In simple words, testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements.
According to ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item.
Who does Testing?
It depends on the process and the associated stakeholders of the project(s). In the IT industry, large companies have a team with responsibilities to evaluate the developed software in context of the given requirements. Moreover, developers also conduct testing which is called Unit Testing. In most cases, the following professionals are involved in testing a system within their respective capacities −
• Software Tester
• Software Developer
• Project Lead/Manager
• End User
Different companies have different designations for people who test the software on the basis of their experience and knowledge such as Software Tester, Software Quality Assurance Engineer, QA Analyst, etc.
It is not possible to test the software at any time during its cycle. The next two sections state when testing should be started and when to end it during the SDLC.
When to Start Testing?
An early start to testing reduces the cost and time to rework and produce error-free software that is delivered to the client. However in Software Development Life Cycle (SDLC), testing can be started from the Requirements Gathering phase and continued till the deployment of the software.
It also depends on the development model that is being used. For example, in the Waterfall model, formal testing is conducted in the testing phase; but in the incremental model, testing is performed at the end of every increment/iteration and the whole application is tested at the end.
Testing is done in different forms at every phase of SDLC −
• During the requirement gathering phase, the analysis and verification of requirements are also considered as testing.
• Reviewing the design in the design phase with the intent to improve the design is also considered as testing.
• Testing performed by a developer on completion of the code is also categorized as testing.
When to Stop Testing?
It is difficult to determine when to stop testing, as testing is a never-ending process and no one can claim that a software is 100% tested. The following aspects are to be considered for stopping the testing process −
• Testing Deadlines
• Completion of test case execution
• Completion of functional and code coverage to a certain point
• Bug rate falls below a certain level and no high-priority bugs are identified
• Management decision
Verification & Validation
These two terms are very confusing for most people, who use them interchangeably. The following table highlights the differences between verification and validation.
This section describes the different types of testing that may be used to test a software during SDLC.
Manual Testing
Manual testing includes testing a software manually, i.e., without using any automated tool or any script. In this type, the tester takes over the role of an end-user and tests the software to identify any unexpected behavior or bug. There are different stages for manual testing such as unit testing, integration testing, system testing, and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test a software to ensure the completeness of testing. Manual testing also includes exploratory testing, as testers explore the software to identify errors in it.
Automation Testing
Automation testing, which is also known as Test Automation, is when the tester writes scripts and uses another software to test the product. This process involves automation of a manual process. Automation Testing is used to re-run the test scenarios that were performed manually, quickly, and repeatedly.
Apart from regression testing, automation testing is also used to test the application from load, performance, and stress point of view. It increases the test coverage, improves accuracy, and saves time and money in comparison to manual testing.
What to Automate?
It is not possible to automate everything in a software. The areas at which a user can make transactions such as the login form or registration forms, any area where large number of users can access the software simultaneously should be automated.
Furthermore, all GUI items, connections with databases, field validations, etc. can be efficiently tested by automating the manual process.
When to Automate?
Test Automation should be used by considering the following aspects of a software −
• Large and critical projects
• Projects that require testing the same areas frequently
• Requirements not changing frequently
• Accessing the application for load and performance with many virtual users
• Stable software with respect to manual testing
• Availability of time
How to Automate?
Automation is done by using a supportive computer language like VB scripting and an automated software application. There are many tools available that can be used to write automation scripts. Before mentioning the tools, let us identify the process that can be used to automate the testing process −
• Identifying areas within a software for automation
• Selection of appropriate tool for test automation
• Writing test scripts
• Development of test suits
• Execution of scripts
• Create result reports
• Identify any potential bug or performance issues
Software Testing Tools
The following tools can be used for automation testing −
• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Testing Anywhere
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• WATIR
There are different methods that can be used for software testing. This chapter briefly describes the methods available.
Black-Box Testing
The technique of testing without having any knowledge of the interior workings of the application is called black-box testing. The tester is oblivious to the system architecture and does not have access to the source code. Typically, while performing a black-box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.
The following table lists the advantages and disadvantages of black-box testing.
Advantages
Disadvantages
Well suited and efficient for large code segments.
Limited coverage, since only a selected number of test scenarios is actually performed.
Code access is not required.
Inefficient testing, due to the fact that the tester only has limited knowledge about an application.
Clearly separates user's perspective from the developer's perspective through visibly defined roles.
Blind coverage, since the tester cannot target specific code segments or error-prone areas.
Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language, or operating systems.
The test cases are difficult to design.
White-Box Testing
White-box testing is the detailed investigation of internal logic and structure of the code. White-box testing is also called glass testing or open-box testing. In order to perform white-box testing on an application, a tester needs to know the internal workings of the code.
The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving inappropriately.
The following table lists the advantages and disadvantages of white-box testing.
Advantages
Disadvantages
As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively.
Due to the fact that a skilled tester is needed to perform white-box testing, the costs are increased.
It helps in optimizing the code.
Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems, as many paths will go untested.
Extra lines of code can be removed which can bring in hidden defects.
It is difficult to maintain white-box testing, as it requires specialized tools like code analyzers and debugging tools.
Due to the tester's knowledge about the code, maximum coverage is attained during test scenario writing.
Grey-Box Testing
Grey-box testing is a technique to test the application with having a limited knowledge of the internal workings of an application. In software testing, the phrase the more you know, the better carries a lot of weight while testing an application.
Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Unlike black-box testing, where the tester only tests the application's user interface; in grey-box testing, the tester has access to design documents and the database. Having this knowledge, a tester can prepare better test data and test scenarios while making a test plan.
Advantages
Disadvantages
Offers combined benefits of black-box and white-box testing wherever possible.
Since the access to source code is not available, the ability to go over the code and test coverage is limited.
Grey box testers don't rely on the source code; instead they rely on interface definition and functional specifications.
The tests can be redundant if the software designer has already run a test case.
Based on the limited information available, a grey-box tester can design excellent test scenarios especially around communication protocols and data type handling.
Testing every possible input stream is unrealistic because it would take an unreasonable amount of time; therefore, many program paths will go untested.
The test is done from the point of view of the user and not the designer.
A Comparison of Testing Methods
The following table lists the points that differentiate black-box testing, grey-box testing, and white-box testing.
Black-Box Testing
Grey-Box Testing
White-Box Testing
The internal workings of an application need not be known.
The tester has limited knowledge of the internal workings of the application.
Tester has full knowledge of the internal workings of the application.
Also known as closed-box testing, data-driven testing, or functional testing.
Also known as translucent testing, as the tester has limited knowledge of the insides of the application.
Also known as clear-box testing, structural testing, or code-based testing.
Performed by end-users and also by testers and developers.
Performed by end-users and also by testers and developers.
Normally done by testers and developers.
Testing is based on external expectations - Internal behavior of the application is unknown.
Testing is done on the basis of high-level database diagrams and data flow diagrams.
Internal workings are fully known and the tester can design test data accordingly.
It is exhaustive and the least time-consuming.
Partly time-consuming and exhaustive.
The most exhaustive and time-consuming type of testing.
Not suited for algorithm testing.
Not suited for algorithm testing.
Suited for algorithm testing.
This can only be done by trial-and-error method.
Data domains and internal boundaries can be tested, if known.
Data domains and internal boundaries can be better tested.
There are different levels during the process of testing. In this chapter, a brief description is provided about these levels.
Levels of testing include different methodologies that can be used while conducting software testing. The main levels of software testing are −
• Functional Testing
• Non-functional Testing
Functional Testing
This is a type of black-box testing that is based on the specifications of the software that is to be tested. The application is tested by providing input and then the results are examined that need to conform to the functionality it was intended for. Functional testing of a software is conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements.
There are five steps that are involved while testing an application for functionality.
Steps
Description
I
The determination of the functionality that the intended application is meant to perform.
II
The creation of test data based on the specifications of the application.
III
The output based on the test data and the specifications of the application.
IV
The writing of test scenarios and the execution of test cases.
V
The comparison of actual and expected results based on the executed test cases.
An effective testing practice will see the above steps applied to the testing policies of every organization and hence it will make sure that the organization maintains the strictest of standards when it comes to software quality.
Unit Testing
This type of testing is performed by developers before the setup is handed over to the testing team to formally execute the test cases. Unit testing is performed by the respective developers on the individual units of source code assigned areas. The developers use test data that is different from the test data of the quality assurance team.
The goal of unit testing is to isolate each part of the program and show that individual parts are correct in terms of requirements and functionality.
Limitations of Unit Testing
Testing cannot catch each and every bug in an application. It is impossible to evaluate every execution path in every software application. The same is the case with unit testing.
There is a limit to the number of scenarios and test data that a developer can use to verify a source code. After having exhausted all the options, there is no choice but to stop unit testing and merge the code segment with other units.
Integration Testing
Integration testing is defined as the testing of combined parts of an application to determine if they function correctly. Integration testing can be done in two ways: Bottom-up integration testing and Top-down integration testing.
Sr.No.
Integration Testing Method
1
Bottom-up integration
This testing begins with unit testing, followed by tests of progressively higher-level combinations of units called modules or builds.
2
Top-down integration
In this testing, the highest-level modules are tested first and progressively, lower-level modules are tested thereafter.
In a comprehensive software development environment, bottom-up testing is usually done first, followed by top-down testing. The process concludes with multiple tests of the complete application, preferably in scenarios designed to mimic actual situations.
System Testing
System testing tests the system as a whole. Once all the components are integrated, the application as a whole is tested rigorously to see that it meets the specified Quality Standards. This type of testing is performed by a specialized testing team.
System testing is important because of the following reasons −
• System testing is the first step in the Software Development Life Cycle, where the application is tested as a whole.
• The application is tested thoroughly to verify that it meets the functional and technical specifications.
• The application is tested in an environment that is very close to the production environment where the application will be deployed.
• System testing enables us to test, verify, and validate both the business requirements as well as the application architecture.
Regression Testing
Whenever a change in a software application is made, it is quite possible that other areas within the application have been affected by this change. Regression testing is performed to verify that a fixed bug hasn't resulted in another functionality or business rule violation. The intent of regression testing is to ensure that a change, such as a bug fix should not result in another fault being uncovered in the application.
Regression testing is important because of the following reasons −
• Minimize the gaps in testing when an application with changes made has to be tested.
• Testing the new changes to verify that the changes made did not affect any other area of the application.
• Mitigates risks when regression testing is performed on the application.
• Test coverage is increased without compromising timelines.
• Increase speed to market the product.
Acceptance Testing
This is arguably the most important type of testing, as it is conducted by the Quality Assurance Team who will gauge whether the application meets the intended specifications and satisfies the client’s requirement. The QA team will have a set of pre-written scenarios and test cases that will be used to test the application.
More ideas will be shared about the application and more tests can be performed on it to gauge its accuracy and the reasons why the project was initiated. Acceptance tests are not only intended to point out simple spelling mistakes, cosmetic errors, or interface gaps, but also to point out any bugs in the application that will result in system crashes or major errors in the application.
By performing acceptance tests on an application, the testing team will reduce how the application will perform in production. There are also legal and contractual requirements for acceptance of the system.
Alpha Testing
This test is the first stage of testing and will be performed amongst the teams (developer and QA teams). Unit testing, integration testing and system testing when combined together is known as alpha testing. During this phase, the following aspects will be tested in the application −
• Spelling Mistakes
• Broken Links
• Cloudy Directions
• The Application will be tested on machines with the lowest specification to test loading times and any latency problems.
Beta Testing
This test is performed after alpha testing has been successfully performed. In beta testing, a sample of the intended audience tests the application. Beta testing is also known as pre-release testing. Beta test versions of software are ideally distributed to a wide audience on the Web, partly to give the program a "real-world" test and partly to provide a preview of the next release. In this phase, the audience will be testing the following −
• Users will install, run the application and send their feedback to the project team.
• Typographical errors, confusing application flow, and even crashes.
• Getting the feedback, the project team can fix the problems before releasing the software to the actual users.
• The more issues you fix that solve real user problems, the higher the quality of your application will be.
• Having a higher-quality application when you release it to the general public will increase customer satisfaction.
Non-Functional Testing
This section is based upon testing an application from its non-functional attributes. Non-functional testing involves testing a software from the requirements which are nonfunctional in nature but important such as performance, security, user interface, etc.
Some of the important and commonly used non-functional testing types are discussed below.
Performance Testing
It is mostly used to identify any bottlenecks or performance issues rather than finding bugs in a software. There are different causes that contribute in lowering the performance of a software −
• Network delay
• Client-side processing
• Database transaction processing
• Load balancing between servers
• Data rendering
Performance testing is considered as one of the important and mandatory testing type in terms of the following aspects −
• Speed (i.e. Response Time, data rendering and accessing)
• Capacity
• Stability
• Scalability
Performance testing can be either qualitative or quantitative and can be divided into different sub-types such as Load testing and Stress testing.
Load Testing
It is a process of testing the behavior of a software by applying maximum load in terms of software accessing and manipulating large input data. It can be done at both normal and peak load conditions. This type of testing identifies the maximum capacity of software and its behavior at peak time.
Most of the time, load testing is performed with the help of automated tools such as Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.
Virtual users (VUsers) are defined in the automated testing tool and the script is executed to verify the load testing for the software. The number of users can be increased or decreased concurrently or incrementally based upon the requirements.
Stress Testing
Stress testing includes testing the behavior of a software under abnormal conditions. For example, it may include taking away some resources or applying a load beyond the actual load limit.
The aim of stress testing is to test the software by applying the load to the system and taking over the resources used by the software to identify the breaking point. This testing can be performed by testing different scenarios such as −
• Shutdown or restart of network ports randomly
• Turning the database on or off
• Running different processes that consume resources such as CPU, memory, server, etc.
Usability Testing
Usability testing is a black-box technique and is used to identify any error(s) and improvements in the software by observing the users through their usage and operation.
According to Nielsen, usability can be defined in terms of five factors, i.e. efficiency of use, learn-ability, memory-ability, errors/safety, and satisfaction. According to him, the usability of a product will be good and the system is usable if it possesses the above factors.
Nigel Bevan and Macleod considered that usability is the quality requirement that can be measured as the outcome of interactions with a computer system. This requirement can be fulfilled and the end-user will be satisfied if the intended goals are achieved effectively with the use of proper resources.
Molich in 2000 stated that a user-friendly system should fulfill the following five goals, i.e., easy to Learn, easy to remember, efficient to use, satisfactory to use, and easy to understand.
In addition to the different definitions of usability, there are some standards and quality models and methods that define usability in the form of attributes and sub-attributes such as ISO-9126, ISO-9241-11, ISO-13407, and IEEE std.610.12, etc.
UI vs Usability Testing
UI testing involves testing the Graphical User Interface of the Software. UI testing ensures that the GUI functions according to the requirements and tested in terms of color, alignment, size, and other properties.
On the other hand, usability testing ensures a good and user-friendly GUI that can be easily handled. UI testing can be considered as a sub-part of usability testing.
Security Testing
Security testing involves testing a software in order to identify any flaws and gaps from security and vulnerability point of view. Listed below are the main aspects that security testing should ensure −
• Confidentiality
• Integrity
• Authentication
• Availability
• Authorization
• Non-repudiation
• Software is secure against known and unknown vulnerabilities
• Software data is secure
• Software is according to all security regulations
• Input checking and validation
• SQL insertion attacks
• Injection flaws
• Session management issues
• Cross-site scripting attacks
• Buffer overflows vulnerabilities
• Directory traversal attacks
Portability Testing
Portability testing includes testing a software with the aim to ensure its reusability and that it can be moved from another software as well. Following are the strategies that can be used for portability testing −
• Transferring an installed software from one computer to another.
• Building executable (.exe) to run the software on different platforms.
Portability testing can be considered as one of the sub-parts of system testing, as this testing type includes overall testing of a software with respect to its usage over different environments. Computer hardware, operating systems, and browsers are the major focus of portability testing. Some of the pre-conditions for portability testing are as follows −
• Software should be designed and coded, keeping in mind the portability requirements.
• Unit testing has been performed on the associated components.
• Integration testing has been performed.
• Test environment has been established.
UML Use Case Diagram
Design Pattern
According to Gang of Four (GOF) definition of design patterns:
“In Software Engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.”
Design patterns are formalized solutions to common programming problems. They mostly refer to object oriented programming, but some of solutions can be applied in various paradigms.
Importance of Design Patterns:
1. Off-the-shelf solution-forms for the common problem-forms.
2. Teaches how to solve all sorts of problems using the principles of object-oriented design.
3. Helps in learning design and rationale behind project, enhances communication and insight.
4. Reusing design patterns helps to prevent subtle issues that can cause major problems.
5. Improves code readability for coders and architects familiar with the patterns.
6. Design patterns provide general solutions, documented in a format that doesn't require specifics
tied to a particular problem.
7. Speed up the development process by providing well tested, proven development/design
paradigm.
Pattern Documentation
1. Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern.
2. Intent: A description of the goal behind the pattern and the reason for using it.
3. Also Known As: Other names for the pattern.
4. Motivation (Forces): A scenario consisting of a problem and a context in which the pattern can be used.
5. Applicability: Situations in which the pattern is usable.
6. Structure: A graphical representation of pattern.
7. Participants: A listing of the classes and objects used in the pattern and their roles in the design.
8. Implementation: A description of an implementation of the pattern; the solution of the pattern.
9. Sample Code: An illustration of how the pattern can be used in a programming language.
10. Known Uses: Examples of real usages of the pattern.
11. Related Patterns: Other patterns that have some relationship with the pattern.
Classification of Design Patterns
Design patterns were originally classified into three types:
1. Creational Patterns
Creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the solution.
- 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
- Prototype: A fully initialized instance to be copied or cloned.
- Singleton: A class of which only a single instance can exist.
2. Structural Patterns
Structural Design patterns are design patterns that ease the design by identifying a simple way to realise relationships between entities.
- 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 tha represents an entire subsystems.
- Flyweight: A fine-grained instance used for efficient sharing.
- Proxy: An object representing another object.
3. Behavioral Patterns
Behavioral design patterns that identify common communication patterns between objects and realise these patterns.
- Chain of Responsibility: A way of passing a request between a chain of objects.
- Command: Encapsulate a command request as an object intepreter.
- Iterator: Sequentially access the elements of a collection.
- Mediator: Defines simplified communication between classes.
- Memento: Capture and restore an objects internal state.
- Observer: A way of notifying change to a number of classes.
- Template Method: Defer the exact step of an algorithm to a subclass.
- Visitor: Defines a new operation to a class without change.
A fourth has since been added
4. Concurrency Patterns
Factory Pattern
Factory pattern is one of the most used design patterns in Java. This type of design pattern comes under creational pattern as this pattern provides one of the best ways to create an object. In factory pattern, we create object without exposing the creation logic to the client and refer to newly created object using a common interface.
Implementation
We are going to create a Shape interface and concrete classes implementing the Shape interface. A factory class ShapeFactory is defined as a next step.
FactoryPatternDemo our demo class will use ShapeFactory to get a Shape object. It will pass information (CIRCLE/RECTANGLE/SQUARE) to ShapeFactory to get the type of object it needs.
Step 1 - Create an interface.
Shape.java
public interface Shape {
void draw();
}
Step 2 - Create concrete classes implementing the same interface.
Rectangle.java
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Inside Rectangle::draw() method.");
}
}
Square.java
public class Square implements Shape {
@Override
public void draw() {
System.out.println("Inside Square::draw() method.");
}
}
Circle.java
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Inside Circle::draw() method.");
}
}
Step 3 - Create a Factory to generate object of concrete class based on given information.
ShapeFactory.java
public class ShapeFactory {
//use getShape method to get object of type shape
public Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
Step 4 - Use the Factory to get object of concrete class by passing an information such as type.
FactoryPatternDemo.java
public class FactoryPatternDemo {
public static void main(String[] args) {
ShapeFactory shapeFactory = new ShapeFactory();
//get an object of Circle and call its draw method.
Shape shape1 = shapeFactory.getShape("CIRCLE");
//call draw method of Circle
shape1.draw();
//get an object of Rectangle and call its draw method.
Shape shape2 = shapeFactory.getShape("RECTANGLE");
//call draw method of Rectangle
shape2.draw();
//get an object of Square and call its draw method.
Shape shape3 = shapeFactory.getShape("SQUARE");
//call draw method of square
shape3.draw();
}
}
Step 5
Verify the output.
Inside Circle::draw() method.
Inside Rectangle::draw() method.
Inside Square::draw() method.
+---------------------------+-------------------------------+
| Singleton | Factory |
+---------------------------+-------------------------------+
| Returns Same instance | Returns various new instances |
| Single Constructor hiding | Multiple Constructors expose |
| No interface | Interface driven |
| No Subclasses | Subclasses |
+---------------------------+-------------------------------+
Singleton Pattern
Singleton pattern is one of the simplest design patterns in Java. This type of design pattern comes under creational pattern as this pattern provides one of the best ways to create an object.
This pattern involves a single class which is responsible to create an object while making sure that only single object gets created. This class provides a way to access its only object which can be accessed directly without need to instantiate the object of the class.
Implementation
We're going to create a SingleObject class. SingleObject class have its constructor as private and have a static instance of itself.
SingleObject class provides a static method to get its static instance to outside world. SingletonPatternDemo, our demo class will use SingleObject class to get a SingleObject object.
Step 1
Create a Singleton Class.
SingleObject.java
public class SingleObject {
//create an object of SingleObject
private static SingleObject instance = new SingleObject();
//make the constructor private so that this class cannot be
//instantiated
private SingleObject(){}
//Get the only object available
public static SingleObject getInstance(){
return instance;
}
public void showMessage(){
System.out.println("Hello World!");
}
}
Step 2
Get the only object from the singleton class.
SingletonPatternDemo.java
public class SingletonPatternDemo {
public static void main(String[] args) {
//illegal construct
//Compile Time Error: The constructor SingleObject() is not visible
//SingleObject object = new SingleObject();
//Get the only object available
SingleObject object = SingleObject.getInstance();
//show the message
object.showMessage();
}
}
Step 3
Verify the output.
Hello World!
Singleton Database Connection
package com.jdbc.util;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class DatabaseConnection {
private static Connection con = null;
static
{
String url = "jdbc:mysql:// localhost:3306/org";
String user = "root";
String pass = "root";
try {
Class.forName("com.mysql.jdbc.Driver");
con = DriverManager.getConnection(url, user, pass);
}
catch (ClassNotFoundException | SQLException e) {
e.printStackTrace();
}
}
public static Connection getConnection()
{
return con;
}
}
2. What Is Inversion of Control?
Inversion of Control is a principle in software engineering by which the control of objects or portions of a program is transferred to a container or framework. It's most often used in the context of object-oriented programming.
By contrast with traditional programming, in which our custom code makes calls to a library, IoC enables a framework to take control of the flow of a program and make calls to our custom code. To enable this, frameworks use abstractions with additional behavior built in. If we want to add our own behavior, we need to extend the classes of the framework or plugin our own classes.
The advantages of this architecture are:
• decoupling the execution of a task from its implementation
• making it easier to switch between different implementations
• greater modularity of a program
• greater ease in testing a program by isolating a component or mocking its dependencies and allowing components to communicate through contracts
Inversion of Control can be achieved through various mechanisms such as:
→ Using a Strategy design pattern
→ Using a Service Locator pattern
→ Using a Factory pattern, and
→ Using a Dependency Injection (DI) of any given below type:
→ A constructor injection
→ A setter injection
→ An interface injection
There are many key differences between constructor injection and setter injection.
1. Partial dependency: can be injected using setter injection but it is not possible by constructor. Suppose there are 3 properties in a class, having 3 arg constructor and setters methods. In such case, if you want to pass information for only one property, it is possible by setter method only.
2. Overriding: Setter injection overrides the constructor injection. If we use both constructor and setter injection, IOC container will use the setter injection.
3. Changes: We can easily change the value by setter injection. It doesn't create a new bean instance always like constructor. So setter injection is flexible than constructor injection.
We're going to look at DI next.
3. What Is Dependency Injection?
Dependency injection is a pattern through which to implement IoC, where the control being inverted is the setting of object's dependencies.
The act of connecting objects with other objects, or “injecting” objects into other objects, is done by an assembler rather than by the objects themselves.
Here's how you would create an object dependency in traditional programming:
public class Store {
private Item item;
public Store() {
item = new ItemImpl1();
}
}
In the example above, we need to instantiate an implementation of the Item interface within the Store class itself.
By using DI, we can rewrite the example without specifying the implementation of Item that we want:
public class Store {
private Item item;
public Store(Item item) {
this.item = item;
}
}
Working Together
Inversion of control can utilize dependency injection because a mechanism is needed in order to create the components providing the specific functionality. Other options exist and are used, e.g. activators, factory methods, etc., but frameworks don't need to reference those utility classes when framework classes can accept the dependency(ies) they need instead.
Examples
One example of these concepts at work is the plug-in framework in Reflector. The plug-ins have a great deal of control of the system even though the application didn't know anything about the plug-ins at compile time. A single method is called on each of those plug-ins, Initialize if memory serves, which passes control over to the plug-in. The framework doesn't know what they will do, it just lets them do it. Control has been taken from the main application and given to the component doing the specific work; inversion of control.
The application framework allows access to its functionality through a variety of service providers. A plug-in is given references to the service providers when it is created. These dependencies allow the plug-in to add its own menu items, change how files are displayed, display its own information in the appropriate panels, etc. Since the dependencies are passed by interface, the implementations can change and the changes will not break the code as long as the contract remains intact.
At the time, a factory method was used to create the plug-ins using configuration information, reflection and the Activator object (in .NET at least). Today, there are tools, MEF for one, that allow for a wider range of options when injecting dependencies including the ability for an application framework to accept a list of plugins as a dependency.
Convention over configuration or Coding by convention is a simple concept that is primarily used in programming. It means that the environment in which you work (systems, libraries, language…) assumes many logical situations by default, so if you adapt to them rather than creating your own rules each time, programming becomes an easier and more productive task.
The goal is to decrease the number of decisions the programmer has to make and eliminate the complexity of having to configure all and each of the areas of application development. The immediate result is that you can create many more things in less time.
Highly successful programming environments such as Ruby on Rails are based on this concept. If you follow the established conventions, you can develop a Rails application in much less time and with many fewer lines of code than you would need developing a similar web application in Java, for example.
If, on the other hand, you want to ignore conventions, you can always replace them with your own code. However, since conventions are not arbitrary, but have been established by a community of high level programmers, it rarely does make sense to waste time overwriting them.
In fact, this concept of convention over configuration is also the basis on which any form of work that requires a certain structure rests. A working methodology like GTD (Getting Things Done), for example, provides a series of conventions for an optimal, personal organization. A concrete series of lists are recommended to be managed, a five-stages work flow is established, and six perspective levels are defined in order to understand the importance of what you do. Other aspects are defined as well, such as the ideal way to review your system or how to plan your projects.
The Convention over Configuration pattern has the following benefits and liabilities:
+ Allows new developers to learn a system quickly. Once developers understand the naming convention, they can quickly start developing without worrying about writing the configurations to make things work. This gives developers the impression that the framework Works Out of the Box15with little or no configuration. Frameworks that work out of the box empowers developers to quickly create prototypes for testing. Compare this to frameworks that require multiple configuration files to get the system up and running even for simple tasks. After they have become more familiar with the framework, they can write configurations for the unconventional cases.
1. + Promotes uniformity. Developers working on different projects but using the same framework can quickly grasp how different systems work since the same naming conventions are promoted throughout the framework. This helps in maintaining a ubiquitous language3 for the development team.
2. + Better dynamism. Changing the name of the class or method in the source code does not require modifying a configuration file. Since the framework does not rely on static configuration files, but rather enforces the naming conventions during runtime, changes made are automatically propagated through the application.
“This is the problem with conventions – they have to be continually resold to each developer. If the developer has not learned the convention or does not agree with it, then the convention will be violated. And one violation can compromise the whole structure.” -Robert C. Martin2”
1. – Requires familiarity. The naming conventions become part of the implicit knowledge of the framework. Once a set of conventions has been established, it becomes hard to change them. In fact, not following those conventions makes the system harder to use. Naming conventions have to be included in the documentation and followed consistently in code samples to avoid confusion.
2. – Larger framework. By shifting the responsibility of configuration from the developer, the framework itself has to enforce those conventions; the set of conventions has to be baked into the framework. If there are a large number of conventions that need to be supported, the framework becomes larger. Thus, only enforce clear and practical naming conventions in the framework itself.
3. – Hard to refactor existing frameworks to adopt a new naming convention. It might not be feasible to use Convention over Configuration when an existing framework has a large group of developers using it. There are currently no automated tools that can upgrade an application to use features in a newer version of the framework. So developers using a version of the framework that used an older convention cannot upgrade easily to a newer convention. The Convention over Configuration pattern is best used during the initial creation of the framework and maintained throughout updates to the framework.
Lazy Initialization of an object means that its creation is deferred until it is first used. Lazy initialization is primarily used to improve performance, avoid wasteful computation and reduce program memory requirements. Lazy initialization is a performance optimization. It's used when data is deemed to be 'expensive' for some reason.
These are the most common scenarios:
1. When you have an object that is expensive to create, and the program might not use it. For example, assume that you have in memory a Customer object that has an Orders property that contains a large area of order objects that, to be initialized, requires a database connection. If the user never asks to display the Orders or use the data in a computation, then there is no reason to use system memory or computation cycle to create it.
Lazy initialization has two objectives:
• delay an expensive operation until it's absolutely necessary
• store the result of that expensive operation, such that you won't need to repeat it again.
Eager Initialization Lazy Initialization
Some examples:
1. Suppose you have Customer object having a big array of orders to display. To display the list to the customer it is very expensive as it requires lot of hits to database. It the Customer object is initialized at the beginning of the program which later found that Customer never asks to display his orders. Now, as you can guess, it is the time for lazy initialization.
2. Another scenario is when an object is very expensive (takes long time to create) to create, if you would like to defer (delay) its creation due to other more expensive operations takes place. Say, your program creates many object instances when it starts, but a few are required immediately. Now lazy initialization is the time to think to increase the startup performance of the program by delaying the initialization after the required and preferred objects have been created. Let us take a small code:
public class Demo
{
private Player newPlayer = new Player(); // object is created well in advance
public Player getPlayer()
{
return newPlayer;
}
public static void main(String args[])
{
Demo d1 = new Demo();
Player p1 = d1.getPlayer();
}
}
When you see this above code, after knowing what is lazy initialization, definitely you say it is meaningless, as the newPlayer object is created at the startup of the program itself which may not be required later (wasting its creation time).
The above code is modified as follows for lazy initialization.
public class Demo
{
private Player newPlayer;
public Player getPlayer()
{
if(newPlayer == null)
{
newPlayer = new Player(); // object is created when asked
}
return newPlayer;
}
public static void main(String args[])
{
Demo d1 = new Demo();
Player p1 = d1.getPlayer();
}
}
In the above code, the creation of newPlayer object is delayed making sure we do not create it until it is required.
Knowledge of the initialization differences is useful in understanding get() vs load() and list() vs iterate().
Eager Initialization
If the program will always need an instance, or if the cost of creating the instance is not too large in terms of time/resources, the programmer can switch to eager initialization, which always creates an instance when the class is loaded into the JVM.
Besides the obvious runtime performance advantages, there are other benefits
to eager initialization:
– Errors are identified earlier.
– There is a clean description of class initialization semantics.
– Class initialization can be precompiled in JVM-to-native (just-in-time) compilation.
The first question that should be answered: Why the web is suitable for developing applications? It is not a difficult question, of course. In the World Wide Web Consortium (W3C) Architecture of the Web Recommendation paper various examples are given, notably one about a user who wants to see the weather in a place where she wants to travel to. The nature of the Internet - trafficking data over protocols from network to network - is a powerful resource that make communication between different places very fast and easy. This way computer programs can be made to improve the relation between systems and people, and what is seen today is that it happened.
Web applications are distributed applications, and hence are at least two-tiered. They act as a special kind of client-server applications, where a large portion of the functionality is “pushed” back to the server side despite the fact that the Web does not define what is behind the server.
The basic two parts for Web Applications
The Web relies strongly in the client-server model, and it uses markup languages such as HTML and XML to transfer and represent data. Under it there are many programming and scripting languages that can dynamically process, modify and generate data, or give an user interface. This way, the development of Web applications can be put under the cover of software engineering but need to be extended. Web applications are multidisciplinary (software engineering, database modeling techniques, network computing, and effective interface design). They are built in a continuously changing environment where requirements are unstable and the user community is wider than before. Web applications handle information from various sources (text, graphics, video, audio) dealing with structuring, processing, storing and presenting this information.
The Three Layers Model
The nature of the Web is layered: it has formats over protocols and uses a client-server model. Therefore, it is natural that a layered architecture would be suitable for developing to the Web. We learnt that this model overcame the two layered client-server because of its scalability. Many different approaches to the aim of developing applications with different layers had been used along the years, but a clear pattern seems to appear frequently in various of them: the Three Layers Model (according to Kappel et al. 2006).
The standard three layered architecture for Web Applications
This model of web application development is very similar to the Service Layer/Domain Model/Data Source Layer set of design patterns from Martin Fowler’s collection, but receiving different names . In fact, the idea ( usually named 3-tier architecture, or expanded into n-tier architecture) is very general and widespread, so in this paper only the most common assumptions and uses are examined.[1]
Its conception is three layers, one over the other, being the application the set of them working together. The most external of them is the View Layer, that is the visible part of the application, the one that interacts with the user. The layer in the middle is the Business Logic Layer, which serves as an intermediate between the View (or presentation) and the innermost layer, that is the Data Layer. This last one is where all the data used by the application is stored.
The benefits of using layered models in software development are in the way that it is easier to know exactly what each part of the application does. It makes easier to construct the application, to debug it, and to maintain and reuse the code. For example, if it is needed to exchange some details in the presentation of the content but the business rules and data models do not change, only one layer is affected. Even for more complicated changes involving all of the application architecture there are benefices, so a plan can be created in the overall but specifying exactly where the changes need to be done.
The View Layer
The outermost layer in this kind of model deals with the presentation of the content and interaction with the user. It can be called view, presentation, UI. In this layer the application shows to the user what is needed to be seen and gives the tools for interaction. The exact kind of interaction depends on the application; one can create a web app that only shows information to the user without any kind of interaction, not even hyperlinks to be clicked, but such a case does not need an advanced architecture. In most cases the user will generate some input, send it for processing and then receive a feedback, that can be the final result or a step for further operations.
Following the example by W3C of the user that wants to see the weather in her trip destination, the presentation is where she sees the actual content. The content display is shown, and the user can interact with the provided controls to, for example, see weather in different periods of time or another places, and see pictures of it.
The technologies usually involved in this layer on the web development context are mainly the markup that is processed by the browser (HTML/ XHTML/ ...), the style of the page (CSS) and client-side scripts (Javascript/ Flash/ ...). All of these tools together can produce a rich environment for user interaction and content display. Of course it can be said that server-side scripts can be used to generate content, but at the final level these scripts produce the HTML that will be shown be the browser, so this role of the development can be subdivided: the content generation is created by the business logic layer (the next topic to be discussed) and then it is passed to the view layer, maintaining the logical division of the application. The browser shows the content initially written or produced by the server-side scripts, and the client-side scripts are able to modify that content. A Javascript code, for example, can be used to validate form data or even to create drag and drop interfaces. It interacts with HTML through a DOM tree, that is a representation of the document in memory. HTML5, the present (2014) trend for web development is praised for its flexibility, specially where it touches the concept of responsiveness, that is the ability to change the content disposition according to the screen size. This matters because, in current days, the availability of a page in different screen sizes and devices is extremely important. Having many possibilities like desktops, tablets, smartphones, wearable devices and even augmented reality or voice user interface, the range of technologies and targets for the view layer is very wide, and it shows both the importance of it to the user and reinforce the need of a logical division of the application for supporting such variety.
This layer communicates with the business logic layer under it, passing the information from the user and controlling it, then giving back any response it produces, not leaving any decisions of the application’s logic to be resolved by the UI. This passing of information is usually done through forms, like a user log-in in a system by giving username and password, but there are other ways. AJAX is an asynchronous way to pass information to the server and get responses. The cited a-synchronicity comes from the fact that in a form the content needs to be passed and then the response will come after a page refresh, but with AJAX the requested information, that is the result of the user’s action will come in the actual page. It saves time and gives to the user the impression that the application is really interacting with him.
The Business Logic Layer
The central layer of the model deals with the logic of the program. It receives data from the upper level and transforms it, using in the inner application logics. It also retrieves data from the deepest data level and uses it to the logics. And, by integrating these two processes, it can do modifications in both levels as well.
The Business Logic Layer contains the determinant part of the application logic. It includes:
• performing all required calculations and validations
• managing workflow
◦ state management: to keep track of application execution
◦ session management: to distinguish among application instances
◦ user identification
◦ service access: to provide application services in a consistent way
• managing all data access for the presentation layer
The Business Logic Layer is generally implemented inside an Application server (like Microsoft Transaction Server, Oracle Application Server, or IBM WebSphere). The Application server generally automates a number of services like transactions, security, persistence, connection pooling, messaging and name services.
Using the same example of the last session, of the user that wants to see the weather in a specific place, when the information is given by the user the application retrieves it and process. For example, the user wants to see the weather forecast for two days. The application receives its request from the UI and the data is sent to the server. A PHP script catches it and then make the calls for the lower level to get the needed data. When a response comes, being it the desired information or a failed request, it is dealt and then prepared to be sent again to the upper level.
The tools used in this level are usually server-side scripts like PHP,ASP.NET, Ruby or CGI. There is even a solution that uses server-side Javascript, called node.js. These technologies, following the information feeding that comes from the upper level, can do any computational pro- cessing that is needed. The CGI (Common Gateway Interface) scripts are an older technology that defines communication way between a server and the content-generated program, in this context called CGI script. One of the most remembered languages when talking about CGI scripts is Perl. The other languages here cited have a similar approach, by running inside a server. PHP is related to Perl, being as well a scripting language and having similar philosophies. It is one of the most popular languages, being the implementation language of important content management systems as Drupal or Wordpress. Ruby have a large popularity too, especially with the framework Ruby on Rails. Applications as Github or Redmine are built using it. There are many others, of course, and different uses of them, one example being C used as CGI or the Java Server Pages (JSP).
The Data Layer
The deepest level in the layered architecture, the data layer deals with data retrieval from its sources. It is an abstraction to get the plain data, that can be in a wide variety of forms. Once again, it plays a huge role on the reusability and exchange of technologies: if one data source is changed to another, but the proper data is still the same, a good layered design can help by providing the same data to the upper level with the same interfaces, changing only its inner logic.
In the example given in this paper of the weather forecast, the requirement by the user for the next days forecast will come to this level as a request for the forecasts that it may have. Then a search will be made in the data using the given parameters, and then the data (or some information about not getting it) will be sent again to the upper level.
The technologies used in this layer are database management systems like MySQL or PostgreSQL for relational databases, NoSQL management systems like MongoDB or Apache Cassandra, or even plain XML files or text files. For the management systems usually an API will be used for making queries and retrieving data, and for the plain text ones a script will do the needed operations. Inside it there can be any level of sophistication desired by the application designer, so there can be integrity checks, stored procedures, and virtually anything needed to maintain the data in the desired state.
Deepest in the Data Layer: NoSQL and NewSQL
Inside the Data Layer, as it was outlined, many different technologies can be used. Most of the web applications currently active use relational databases, but now the market is seeing a change of paradigm in the form of the NoSQL. NoSQL is a general way to identify non-relational databases. Fowler summarises some common characteristics that NoSQL databases share:
• Not using the relational model
• Running well on clusters
• Open-source
• Built for the 21st century web estates
• Schemaless
The key points NoSQL supporters use to justify the need for it is that relational databases are not the best solution for any kind of problem, being a problem of its own the uses. They say it is heavy, slow, and non-scalable to use the relational databases, so the use of NoSQL can be a good way to solve these kinds of problems. The use of NoSQL nowadays seems related to startups that use innovating new technology and social web services such as Facebook and Amazon, that have a great amount of data[2] to deal with and have the need to find new ways to use it.
In fact, that is this demand of large data processing. Under the label of big data lies the concept of large quantities of data generated in the last few years and from different sources and in a variety of different formats. The processing of this kind of data leads to a wide range of uses, from healthcare to criminalistics inferences. Of course, new challenges arises with this perspective. The drawbacks come from the nature of the data - massive, disperse, heterogeneous. This is why NoSQL can be seen as a solution - it thinks about this kind of problem, trying to solve it.
As of 2014, there are four important categories of NoSQL databases:
• key-value stores, that are basically hash tables
• column family stores, which aim is to deal with vast collections of data spread amongst many different machines
• document databases, versioned documents that are collections of other key-value collections
• and graph databases, where the data is presented as a graph, and then it is possible to divide easily into different machines and the queries are more data-specific than the relational ones
A topic that attracts attention when it comes to the issue of scalability and performance of databases is the so-called NewSQL. It is more a way to recognise “ the various emerging database products at this particular point in time”. The authors writing about it use the term as an identification of vendors that provide SQL databases that are high-performance and scalable, in the market that is also aimed by NoSQL providers. The aims of NewSQL are also related to the Big Data paradigm.[3]
J2EE
J2ee
ASP.NET
Model
Simple Java bean classes with setters and getters.
Simple .NET class with business logic with setter and getters.
Controller
Controller is implemented using HttpServlet class.
Controller is implemented using the HttpHandler class.
View
Simple JSP pages.
Simple ASPX page.
The MVC pattern - useful but not a silver bullet
Design patterns try to suggest the way of the application design, while methodologies try to give suitable models for the application and its whole lifecycle. The main idea behind design patterns is to extract the high level interactions between objects and reuse their behaviour from application to application. Moreover, design patterns help to clarify the way that we can think about a Web application.
The MVC architecture has its roots in Smalltalk, where it was originally applied to map the traditional input, processing, and output tasks to the graphical user interaction model. However, it is straightforward to map these concepts into the domain of multi-tier Web applications. It can improve the application’s usability, creating reusable code and helping to understand and clarify the functionality of the program. The MVC pattern is very simple, yet incredible useful. It could support:
• Efficient modularity: allows swapping in and out any of the components as the user or programmer desire. Changing one aspect of the program are not coupled to other aspects
• Reusability: it can support the reuse of previously created code if we act sensibly and design carefully.(Reduces risks of bugs coming from refactoring)
• Ease of growth: controllers and views can grow as the model grow
• Centralized controller: a main module is used to make control more manageable
The MVC architecture
• Model: The model represents enterprise data and the business rules that govern access to and updates of this data.
• View: The view renders the contents of a model. It accesses data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes.
• Controller: The controller translates interactions with the view into actions to be performed by the model. In a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
Although MVC is undoubtedly a valuable and useful way to design Web applications, but not the only one. The MVC design pattern’s importance lies in how could it help to achieve a clear separation of concerns and functional layers. Create a module for the database portion, create another module for the application code, and create a third module for the presentation code. That way, we can swap and change different elements at will, hopefully without affecting the other parts.
Several vendors have applied this design pattern in their solution. As we have seen that the Web application term appeared in the servlet definition from Sun, here we will show the classic version of the MVC pattern's usage in that context (according to Kappel et al. 2006).
The JSP-Model-2 architecture
The Layered Architecture and the MVC Design Pattern
In the context of Web applications, by concentrating too closely on applying the MVC design pattern and nothing else, many other important aspects may be overlooked. This could lead to a fragmented and fragile solution, and as a result, is hard to maintain and execute further development. The MVC is a well known and widely used design strategy, but the problem is, how can we adopt this pattern into the layered model of Web applications?
At first sight the answer could say that we have three layers and three modules, the View module is equivalent with the Presentation layer, the Model module is equivalent with the Data layer, and the Controller module is equivalent with the Business Logic.
But if we take a closer look in the functionality of the Model and the Controller – discussed earlier in the paper – we could find that the Model represents business rules, and the Controller translates the interactions ( HTTP GET, POST requests).
These suggest that the Controller is only a part of the Business Logic Layer and the Model forms the other part of the Business Logic Layer. We must take under consideration this heterogeneous composition of the Business Logic Layer through the development of a Web-based application.
MVC and the Layers
It should be obvious by now that MVC or any other design pattern is no more a silver bullet by itself than object-oriented programming is. It's just one part of a much bigger system. We know that MVC has several advantages:
• Clean separation of different functional layers
• Reduces maintenance costs
• Reduces risks of bugs coming from refactoring, graphics redesign
• Presence of a central controller raises overall software security level
• Controller can centrally perform tasks like access logging – without central controller such a task would affect the source code if all business logic actions.
but we also know the drawbacks:
• More software design cost (short term)
• More implementation cost
• Programmers cannot use some comfortable system features
• Programmers may feel they are forced to program a complicated way instead of quickly implementing.
MVC – Servlet, POJO
Design considerations
Presentation Layer
Business Layer
ROA is API wrappers over data models, SOA is API over functional modules.
ROA is used to provide CRUD operations. SOA is used to link modules at run time.
ROA insulates API consumers from changes to data models. SOA allows drop in replacements of modules, simplifying deployment and customisation.
The Payload of an API Module is the body of your request and response message. It contains the data that you send to the server when you make an API request. You can send and receive Payload in different formats, for instance JSON.
How to prevent XSS attacks
Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.
In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:
• Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
• Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
• Use appropriate response headers. To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
• Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
XSS
Let's look at how simple an XSS attack can be. The XYZ football club's message board allows club members to post comments about the team and its performance. Comments are stored in an online database and displayed to other members without ever being validated or encoded. A malicious member can simply post a comment containing a script enclosed by the <script> tags. The attacker then waits for other members to view the comment. Since the text inside a <script> tag is not generally displayed, other members may not even be aware that the script has executed; merely viewing the comment will execute the script. The script can legitimately request the member's cookie information and pass it to the attacker. This type of XSS attack is known as persistent XSS because the malicious script is rendered more than once
Client-side validation cannot be relied upon, but user input can be forced down to a minimal alphanumeric set with server-side processing before being used by your Web application in any way. You can use regular expressions to search and replace user input to ensure it's non-malicious. This cleaning and validation should be performed on all data before passing it on to another process. For example, a phone number field shouldn't accept any punctuation other than parentheses and dashes. You also need to encode special characters like "<" and ">" before they are redisplayed if they are received from user input. For example, encoding the script tag ensures a browser will display <script> but not execute it. In conjunction to encoding, it is important that your webpages always define their character set so the browser won't interpret special character encodings from other character sets.
TDD Java example
TDD is a separate paradigm. During learning, developer skills and advantages of the approach grow. Consider the technique as a contribution to the future. Changes affect application documentation and unit tests representing executable specifications. Tests are used to verify compliance with requirements and describe them. A great difficulty for a Java software developer is creating a roadmap for complex functionality in the form of planned tests.
The methodology detects bugs in the early stages, which reduces the cost of finding a solution. Therefore, the developer confidently proceeds refactoring and continuous improvement.
Development with TDD implies that we need to create test cases first, and then establish the requirements for implementation. Then we will create the code for the implementation to conduct the tests.
In simple words, there are 3 steps in each cycle:
1. Writing tests
2. Implementing features
3. Refactoring
In the first case, we determine the requirements in the form of tests, then we conduct the test without cleaning and improving the code, and in the last step, we improve the code, making it easier to read and maintain.
SEE ALSO: Best practices for securing CI/CD pipelines, or how to get security right
Examples of code snippets
public class CustomItem<E> implements Item<E> {
private Object[] internal = {};
// new empty implementation methods
}
@Override
public boolean isExist() {
return false;
}
@Override
public boolean isExist() {
return true;
}
Agile methodology is a practice that helps continuous iteration of development and testing in the SDLC process. Agile breaks the product into smaller builds.
In this methodology, development and testing activities are concurrent, unlike other software development methodologies. It also encourages teamwork and face-to-face communication. Business, stakeholders, and developers and clients must work together to develop a product.
Scrum in Agile is a process that allows software development teams to focus on delivering business values in shortest time by rapidly and repeatedly inspecting actual working software. It focuses on accountability, teamwork and iterative progress towards well-defined goals. Scrum Framework usually deals with fact that requirements are likely to change or mostly not known at the beginning of project.
KEY DIFFERENCE
• Agile is a continuous iteration of development and testing in the software development process whereas Scrum is an Agile process to focus on delivering the business value in the shortest time.
• Agile methodology delivers the software on a regular basis for feedback while Scrum delivers the software after each sprint.
• In the Agile process, leadership plays a vital role; on the other hand, Scrum fosters a self-organizing, cross-functional team.
• Agile involves collaborations and face-to-face interactions between the members of various cross-functional teams whereas Scrum collaboration is achieved in daily stand up meetings.
• In Agile process design and execution should be kept simple whereas in Scrum process design and execution can be innovative and experimental.
Agile
Scrum
Agile is a development methodology based on iterative and incremental approach.
Scrum is one of the implementations of agile methodology. In which incremental builds are delivered to the customer in every two to three weeks' time.
Agile software development has been widely seen as highly suited to environments which have small but expert project development team
Scrum is ideally used in the project where the requirement is rapidly changing.
In the Agile process, the leadership plays a vital role.
Scrum fosters a self-organizing, cross-functional team.
Compared to Scrum it is a more rigid method. So there is not much room for frequent changes.
The biggest advantage of Scrum is its flexibility as it quickly reacts to changes.
Agile involves collaborations and face-to-face interactions between the members of various cross-functional teams.
In Scrum, collaboration is achieved in daily stand up meeting with a fixed role assigned to scrum master, product owner, and team members.
Agile can require lots of up-front development process and organizational change.
Not too many changes needed while implementing scrum process.
The agile method needs frequent delivery to the end user for their feedback.
In the scrum, after each sprint, a build is delivered to the client for their feedback.
In this method, each step of development like requirements, analysis, design, are continually monitored during the lifecycle.
A demonstration of the functionality is provided at the end of every sprint. So that regular feedback can be taken before next sprint.
Project head takes cares of all the tasks in the agile method.
There is no team leader, so the entire team addresses the issues or problems.
The Agile method encourages feedback during the process from the end user. In this way, the end product will be more useful.
Daily sprint meeting is conducted to review and feedback to decide future progress of the project.
Deliver and update the software on a regular basis.
When the team is done with the current sprint activities, the next sprint can be planned.
Design and execution should be kept simple.
Design and execution can be innovative and experimental.
In the Agile method, the priority is always to satisfy the customer by providing continuous delivery of valuable software.
Empirical Process Control is a core philosophy of Scrum based process.
Working software is the most elementary measure of progress.
Working software is not an elementary measure.
It is best to have face-to-face communication, and techniques like these should be used to get as close to this goal as possible.
Scrum team focus to deliver maximum business value, from beginning early in the project and continuing throughout.
Following are Agile principles:
-Welcome changing requirements, even late in development. Agile processes allow change according to customer's competitive advantage.
-Business people and developers will work daily throughout the project.
-Attention to technical excellence and right design enhances agility
-Agile team, work on to become more effective, for that they adjust its behavior according to the project.
Following are scrum principles:
-Self-organization: This results in healthier shared ownership among the team members. It is also an innovative and creative environment which is conductive to growth.
-Collaboration: Collaboration is another essential principle which focuses collaborative work. 1. awareness 2. articulation, and 3. appropriation. It also considers project management as a shared value-creation process with teams working together to offer the highest value.
-Time-boxing: This principle defines how time is a limiting constraint in Scrum method. An important element of time-boxed elements are Daily Sprint planning and Review Meetings.
-Iterative Development: This principle emphasizes how to manage changes better and build products which satisfy customer needs. It also defines the organization's responsibilities regarding iterative development.
What is Agile Testing?
AGILE TESTING is a testing practice that follows the rules and principles of agile software development. Unlike the Waterfall method, Agile Testing can begin at the start of the project with continuous integration between development and testing. Agile Testing methodology is not sequential (in the sense it's executed only after coding phase) but continuous.
The scrum master is responsible for ensuring a true scrum process over the course of a project. They hold together the scrum framework, facilitating the process for the organization, product owner and scrum team. The scrum master is the person on the team who is responsible for managing the process, and only the process. They are not involved in the decision-making, but act as a lodestar to guide the team through the scrum process with their experience and expertise.
An Agile retrospective is a meeting that's held at the end of an iteration in Agile software development (ASD ). During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward.
Each member of the team members answers the following questions:
• What worked well for us?
• What did not work well for us?
• What actions can we take to improve our process going forward?
In Agile product development, a sprint is a set period of time during which specific work has to be completed and made ready for review.
Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria need to be met for the work to be approved and accepted.
The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the team to complete.
A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. Burn down charts are a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum. However, burn down charts can be applied to any project containing measurable progress over time.
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective. A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1][2][3] it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, not programming features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.[2][3][4] The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair programming.
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
Enterprise Application Development Notes
![Enterprise Application Development Notes]()
Reviewed by Nischal Lal Shrestha
on
November 26, 2021
Rating:
Subscribe to:
Post Comments
(
Atom
)
Posts
No comments: