0% found this document useful (0 votes)
75 views13 pages

Crash Notes

The document defines and describes various concepts related to software development including programming languages, models, testing techniques, diagrams, errors, and more. Specifically, it discusses XML, HTML, blackbox testing, waterfall model, requirement analysis, system design, testing phases, UML diagrams, object oriented concepts, design models, software testing attributes, coupling, cohesion, and common coding errors.

Uploaded by

Dereddy Mani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
75 views13 pages

Crash Notes

The document defines and describes various concepts related to software development including programming languages, models, testing techniques, diagrams, errors, and more. Specifically, it discusses XML, HTML, blackbox testing, waterfall model, requirement analysis, system design, testing phases, UML diagrams, object oriented concepts, design models, software testing attributes, coupling, cohesion, and common coding errors.

Uploaded by

Dereddy Mani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

XML = Extensible markup Language

ASCIE = American standard code for information exchange

XML doesn’t use predefined tags like HTML, Author must define
tags and content in XML

XML is designed to carry data, HTML is designed to display data

Blackbox testing = The technique of testing in which the tester


doesn’t have access to the source code of the software.

WhiteBox testing = The techniques of testing in which the tester


is aware of the internal workings of the product.

Waterfall Model = Requirement analysis-> system design ->


implementation-> testing -> deployment -> Maintenance

Requirement analysis phase = Detail requirements of the


software system to be developed are gathered from clints

System Design = Plan the programming language, for example


java, PHP, .net

Built Stage = Start to code the software


Testing = You test the software to verify that it is built as per the
specifications given by the clint

Deployment stage = Deploy the application in the respective


environment

Maintenance stage = Once your system is ready to use, you may


later require to change the code as per customer request.

SDLC = Software development lifecycle

V- Shape Model = Also referred to as the verification and


validation model, Testing of the device is planned in parallel with
a corresponding stage of development.

Verification = (are you building the product right?) (Verification


is static Testing) Verification is the process of checking that a
software achieves its goal without any bugs, and give the result.
It is the process of ensure whether the product that is developed
is right or not. It verifies whether the developed product fulfills
the requirements that we have.

Validation = (Are we building the right product?) (Validation is


the process) Validation is the process of checking whether the
software product is up to the mark or in other words product has
high level requirements. It is the process of checking the
validation of productsi.r it checks what we are developing is the
right product.

Testing Phases in V-shape model =

Unit testing = Unit testing tests individual units at unit level for
bugs. Unit test plans are developed during the module design
phase.

Integration testing = In integration testing, the modules are


integrated and system is tested. Integration testing is performed
on the architecture design phase. This test verifies the
communication of module among themself

System testing: System testing test the complete application


with its functionality, inter dependency, and communication.It
tests the functional and non-functional requirements of the
developed application.

Acceptance testing: acceptance testing is performed in a user


environment that resembles the production environment. This
testing verifies that the delivered system meets user
requirements.
Design Phases in V-shape model =

Requirement analysis phase = Detail requirements of the


software system to be developed are gathered from clints

System Design = Plan the programming language, for example


java, PHP, .net

Architectural Design = System design is broken down further


into modules taking up different functionalities. The data
transfer and communication between the internal module and
the outside world is clearly understood.

Module design = this phase the system breaks down into small
modules. The Detail design of modules is specified, also know as
low-level Design (LLD).
UML = Unified Model language is not a programming language, it
is rather a visual language. We Use UML diagrams to portray the
behavior and structure of a system.

UML is classified into two types = Structural and Behavior


diagrams

Structural diagrams are = Captures static Aspects or structure of


a system. Structural Diagrams include: Component Diagrams,
Object Diagrams, Class Diagrams and Deployment Diagrams.
Behavior Diagrams are = Capture Dynamic Aspects or behavior
of the system. Behavior Diagrams Include: Use case Diagrams,
State Diagrams, Activity Diagrams and interaction Diagrams.

Object Oriented concepts used in UML are:

Class = Class is a user-Defined datatype that contains its own


Data members and member functions. A Class is used to
organize information or data so a programmer can reuse the
elements in multiple instances through object.

Object = An Object is an instance of a class, All the data


members and member functions of the class can be accessed
with the help of objects.

Abstraction = Mechanism by which Implementation details are


hidden from users. Complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification
of the essentials.

Encapsulation = Encapsulation is also called an information


hiding concept. The data and operations are linked to a single
unit. Encapsulation not only bundles essential information of an
object together but also restricts access to the data and
methods from the outside world.
Inheritance = Inheritance is a mechanism by which child classes
inherit the properties of their parent classes.

Polymorphism = OOD (Object Oriented Design) languages


provide a mechanism where methods perform similar tasks but
very in arguments, can be assigned the same name. This is know
as polymorphism

Top-Down design Model = Top-down model is a system design


approach where the design stats from the system as a whole.
The Complete System is then divided into smaller Sub-
applications with more details. Each part agin goes through the
top-down approach till the complete system is designed with
minute details. Top-down is also termed as breaking a bigger
problem into smaller problems and solving them individually in
a recursive manner.

Bottom-Up design model = Bottom-Up model is a system design


approach where the parts of a system are defined in details.
Once these parts are designed and developed, then these parts
or components are linked together to prepare a bigger
component. This approach is repeated until the complete
system is build. THe advantage of bottom-up model is in making
decision at very low level and to decide the reusability of
components.
Software testing = A good Software testing attributes are
(Reliability, Scalability, Portability, Re-Usability, Usability)

Coupling = Coupling refers to the degree of interdependence


between modules or components in a software system. A good
software will have low coupling. The high coupling means a
module is highly dependent, low coupling means it is more
independent. The goal is to have low coupling, which allows for
greater flexibility and maintainability in the software system.

Common Coupling = When two or more module share the same


global data. Its common coupling

External Coupling = When software module interacts with


elements outside of its control and can change independently,
such as other software system, user interfaces, etc.

Control Coupling = When one module controls the execution of


another. Its control coupling.

Stamp Coupling = When Module requires a specific


implementation of another module. Its called Stamp Coupling.
Data Coupling = When Modules share data through parameters
or return values.

Content Coupling = When a Modules directly accesses the data


of another module.

Cohesion = Cohesion refers to the degree to which elements


within a single module or component work together to achieve a
single purpose. A good software will have high cohesion. High
Cohesion means elements are tightly related and work together
to achieve a specific goal. Low Cohesion means elements are
loosely related and do not have a clear purpose.

Functional Cohesion = When all elements within a module are


related to a single, well - defined function. Its Functional
Cohesion.

Procedural Cohesion = When elements within a module are


organized as a series of steps to achieve a function.

Temporal Cohesion = When elements within a module are


related by the time at which they are executed.
Sequential Cohesion = When elements within a module are
organized in a specific sequence to achieve a function. Its
Sequential Cohesion.

Layer Cohesion = When all the elements within a single layer are
related to a single purpose and work together to achieve that
purpose.

Communication cohesion = This type of cohesion occurs when


elements within a module are related by the data they
manipulate.

Common Coding errors

Logic Error = Code executes well but, i don't provide a desire out.
These can be miscalculations, illogical decisions.

Runtime error = These bugs occur when the code “ won’t play
nice” with another computer, even if it worked perfectly fine on
the developer’s own computer. These errors are especially
frustrating because they directly impact the end user and make
the application appear unreliable or even completely broken.

Compilation errors = Compilation is the process of converting a


high-level coding language into a lower-level language that can
be better understood by the computer. Compilation errors occur
when the compiler isn’t able to properly transform the high-level
code into the lower-level one. This prevents the software from
Being launched or tested.

Syntax errors = Computer languages have their own specialized


grammar rules. When these rules aren’t followed, a syntax error
occurs.

Interface errors = These bugs typically happen when the input


the software receives does not conform to the accepted
standards. When handled incorrectly, these errors can look like
errors on your side even when they’re on the caller’s side, and
vice versa.

Resource errors = sometimes, a programm can force the


computer it’s running on to attempt to allocate more resources
(ram, disk space). The results in the program becoming bugged
or even causing the entire system to crash.

Arithmetic errors = THese errors are just like logic errors, but with
mathematics.
Data Flow Diagram = Data flow diagram is a traditional visual
representation of the information flows within a system. It shows
how the data enters and leaves the system, what changes the
information, and where data is stored. The objective of a DFD is to
show the scope and boundaries of a system as a whole. The DFD
is also called as a data flow graph or bubble chart.

The following observations about DFDs are essential:


1. All names should be unique.
2. Remember that DFD is not a flow chart. Arrows in a flow
chart that represents the order of events. Arrows in DFD
represent flowing data.
Use Case Diagrams = Use case diagrams are part of UML(UNified
modeling language), it comes under behavior diagrams in UML.
Along with other four diagrams (Activity, Sequence,
Collaboration and statechart). The Purpose of use case diagram
is to capture the dynamic aspects of a system. USe case
diagrams are used to gather the requirements of a system
including internal and external influences.

The purpose of use case diagrams can be said to be as follows =


1. Used to gather the requirements of a system
2. Used to get an outside view of a system
3. Identify the external And internal Factors influencing the
system.
4. Show the interaction among the requirements are actors.

Actors can be human users, some internal applications, ot


maybe some external Applications. When we are planned to
dram a use case diagram, we should have the following items
identified.
1. Functionalities to be represented as use case
2. Actors
3. Relationships among the use cases and actors.
Activity Diagrams = We use Activity diagrams to illustrate the
flow of a control in a system. And refer to the steps involved in
the execution of a use case. We model sequential and concurrent
activities using an activity diagram. We describe or depict what
causes a particular event using a activity diagram.

Sequence Diagrams = Sequence diagrams are part of


UML(Unified modeling language), under behavior diagrams. A
Sequence diagrams simply depicts interaction between objects
in a sequential order i.e. The order in which these interactions
take place. ITs also called event diagrams.

SRS (Software requirements specifications) =

You might also like