There are three stages in this process. These are:

 Qualification,
 Adaptation (also known as wrapping),
 Composition (all in the context of components).

Component qualification: examines reusable components. These are identified by characteristics in their interfaces, i.e., the services provided, and the means by which consumers access these services. This does not always provide the whole picture of whether a component will fit the requirements and the architectural style. This is a process of discovery by the Software Engineer. This ensures a candidate component will perform the function required, and whether it is compatible or adaptable to the architectural style of the system. The three important characteristics looked at are performance, reliability and usability.

Component Adaptation is required because very rarely will components integrate immediately with the system. Depending on the component type(e.g., COTS or inhouse), different strategies are used for adaptation (also known as wrapping). The most common approaches are:

 White box wrapping: The implementation of the component is directly modified in order to resolve any incompatibilities. This is, obviously, only possible if the source code is available for a component, which is extremely
unlikely in the case of COTS.

 Grey box wrapping: This relies on the component library providing a component extension language or API that enables conflicts to be removed or masked.

 Black box wrapping: This is the most common case, where access to source code is not available, and the only way the component can be adapted is by pre / post-processing at the interface level.

It is the job of the software engineer to determine whether the effort required to wrap a component adequately is justified, or whether it would be “cheaper” (from a software engineering perspective) to engineer a custom component which removes these conflicts. Also, once a component has been adapted it is necessary to check for compatibility for integration and to test for any unexpected behavior which has emerged due to the modifications made.

 Ans : The following are the similarities and the differences between the Cleanroom software engineering development and OO software engineering paradigm.

Similarities
 Lifecycle - both rely on incremental development
 Usage - cleanroom usage model similar to OO use case
 State Machine Use - cleanroom state box and OO transition diagram
 Reuse - explicit objective in both process models

Key Differences
 Cleanroom relies on decomposition and OO relies on composition
 Cleanroom relies on formal methods while OO allows informal use case definition and testing
 OO inheritance hierarchy is a design resource whereas cleanroom usage hierarchy is system itself
 OO practitioners prefer graphical representations while cleanroom practitioners prefer tabular representations
 Tool support is good for most OO processes, but usually tool support is only found in cleanroom testing, not design.

 A formal method in software development is a method that provides a formal language for describing a software artifact (e.g., specifications, designs, source code) such that formal proofs are possible, in principle, about properties of the artifact so expressed.

Mathematics supports abstraction and therefore is a powerful medium for modeling. Because they are exact, mathematical specifications are unambiguous and can be validated to uncover contradictions and incompleteness. It allows a developer to validate a specification for functionality. It is possible to demonstrate that a design matches a specification, and that some program code is a correct reflection of a design

How is the mathematics of formal languages applied in software development? What engineering issues have been addressed by their application? Formal methods are of global concern in software engineering. They are directly applicable during the requirements, design, and coding phases and have important consequences for testing
and maintenance.

They have influenced the development and standardization of many programming languages, the programmer’s most basic tool. They are important in ongoing research that may change standard practice, particularly in the areas of
specifications and design methodology. They are entwined with lifecycle models that may provide an alternative to the waterfall model, namely rapid prototyping, the Cleanroom variant on the spiral model, and “transformational” paradigms.

The concept of formalism in formal methods is borrowed from certain trends in 19th and 20th century mathematics. Formal methods are merely an adoption of the axiomatic method, as developed by these trends in mathematics, for software engineering. Mastery of formal methods in software requires an understanding of this mathematics background. Mathematical topics of interest include formal logic, both the propositional calculus and predicate logic, set theory, formal languages, and automata such as finite state machines.

The OECD an international organization working in the area of data privacy and information security, established an ad hoc process of meetings (the first was on 1-2 July 1997 and second on 22 October 1997) on approaches being taken in major industrial countries for the regulation of content conduct on the Internet. The meeting acknowledged the primary role of the private sector in regulating the Internet. However, at the joint OECD/Business and Industry Advisory Committee forum held on 25 March 1998 in Paris, the OECD resolved to do no further work in this area. On 19 April 2006, OECD task force on spam has recommended that Governments and industry should step up their coordination to combat the global problem of spam. It calls on governments to establish clear national anti-spam policies and give enforcement authorities more power and resources. Co-ordination and co-operation between public and private sectors are critical, the report notes.

• It is faster than stream cipher.
• If any block contains any transmission error then it will not have affect on other blocks.
• It is not sufficient in hardware but may be used to connect keyboard to CPU (central process unit)
• Block ciphers can be easier to implement in software, because there is no bit manipulation like in stream cipher which is time consuming process and treats data in computer-sized blocks
• Block Cipher is more suitable in trading applications.
• Short blocks at the end of a message can also be added with blank or zero status.