Archive for the ‘Corporate software’ Category

Apache Attempts Decisive Plan of Action Against Oracle’s Java-Monopoly

apache_software_foundation_logo_3074Apache Software Foundation (ASF) was reelected member of Java Community Process (JCP) Executive Committee with 95 % of voices for a standard term of three years. The representatives of Eclipse Foundation, Google, Red Hat and other companies were also elected to the committee. In its address regarding this event, Apache Executive Committee thanks the community for the support and again tackles the key issue of licensing Java for the use in open applications and to the old problem of licensing limitations in tests for compatibility with Java SE.

Apache representatives also point out that if the limitations aren’t removed it won’t maintain its membership in JCP. “We don’t want membership in the organization for which law means nothing. Our membership under such conditions is fraudulent as it demonstrates that the community means nothing, and we promote solutions exceptionally for Oracle’s interests irrespective of the fact whether they coincide with the interests of the community”, says Jim Jagielski, President and Co-Founder of Apache Software Foundation.

The situation has now reached a critical point. Apache hopes to use its influence to make Oracle drop its Field-of-Use limitations included in the license. The re-election into the committee became positive news for Apache given rather a complicated period, since some time before that IBM announced its decision to stop supporting the Harmony project in favor of OpenJDK.

IBM was one of the most reliable and consistent allies of Apache in FOU. It is possible to assume that this step in the direction of OpenJDK means that at the upcoming voting for Java 7 IBM will support Oracle. In this case, it will join the organizations which believe that Oracle’s actions shouldn’t be interfered with for the sake of developing Java in general. In fact, Red Hat and Eclipse Foundation adhere to this idea.

Consequently, according to Jagielski, the chief question for Apache is now the future of Harmony. Without Harmony the participation of Apache in JCP will be useless and even artificial. Oracle is obviously seeking profit through the commercial licensing of Java. Larry Ellison said Java was the most valuable acquisition of all which became possible due to the purchase of Sun.

Apache doesn’t want to slow down the development of Java, said Jangielski, but at the same time the vote for the adoption of Java 7 (provided it still has licensing limitations) will put Apache in the improper situation. The decision to stay or leave the JCP Executive Committee will depend on the seriousness of the support Apache will get. “If the voting for Java 7 is negative it will mean that JCP still reflects processes which take place in society, and in this case we’ll stay and fight actively”. Oracle made no comments on the situation.

How to Introduce Architecture and its Changes

The specifics of describing architecture and its changes is in the fact that as opposed to a program code it has no evident representation, except for those cases when it is clearly documented. However, even in this case it is hard to guarantee the correspondence of documented architecture to the factual high-level logical structure which in reality exists in the system.

Structural models can become means of describing architecture and its changes. There are currently a large number of notations and tools supporting structural modeling of software. The possibility of the automatic extraction of models from a code guarantees their precision and allows for their timely updating. This possibility becomes crucial for choosing the necessary tools as the compliance of the model with the factual structure of the existing code in the process of modeling the architecture and its changes happens to be exceptionally important for securing a precise and manageable process.

For the further study of program systems architecture we will use a notation of structural modeling accepted in KLOCwork Architect tool which allows for the automatic extraction of models from a program code and their editing. Here is a brief review of the notation:

Program system models utilized by KLOCwork Architect are somewhat similar to Entity-Relation models. They belong to a class of container models. The model’s basic elements are as follows:

Architecture Block.KLOCwork Architect model consists of so called architecture blocks. Architecture blocks introduce into models structural elements of a program system irrespective of the level of abstraction in which the modeling takes place. Architecture blocks have at least two major attributes, such as name and type. Names of architecture blocks are predetermined by the names of those structural elements of the system which they introduce into models. Types of architecture blocks substantially depend on the level of abstraction where modeling takes place, and a concrete task within which the research of the architecture is carried out. For example, to model systems built within any component technologies “components” will be the type of architecture blocks used. For modeling systems of building software the chiefly used types will be “folders” and “files”.

Relation. In the model KLOCwork Architect relation means a one-way relation between a pair of architecture blocks. Just like architecture blocks, relations can be of various types. The following types of relations can be used as an example:

Instancing: A instances B (block A is a function, block B is a class).

Access to data: A reads data from B (block A is a function, block B is a class or a class attribute).

Between any pair of blocks there can be a random number of differently directed relations. Their types can also be differentiated at the same time.

Architecture Refactoring

architecture_toolsRefactoring is one of the most successful approaches to changing existing software. It is the approach based on systematic transformations of the initial code. Refactoring is the change in the internal structure of software aimed at facilitating the understanding of how it works and simplifying the modification without tackling the observed behavior. It is commonly understood that during a software development process the system design is created first and only then is its code is written. In the course of time the code is modified and the system wholeness, i.e. the correspondence of its structure to the initial design slowly gets worse. The further development of the system gradually shifts from a directed, guided activity to hacking. Refactoring appears to be quite the opposite practice. With its help any chaotic and misguided project can be transformed into a well-designed code. Each step of the process is quite simple. For example, one of the steps involves transferring the field or method from one class into another, class separation, etc. However, the total effect of such minor and seemingly insignificant changes proves to be cumulative and can radically change a project for better. The process of refactoring is a direct opposite to a gradual system code degradation.

For documenting and cataloguing refactoring methods, one uses semiformal notation in which every method is described by means of a so-called pattern. Any pattern describes and names typical tasks which constantly appear in the process of work, and also the principle of their solution. As a result, such solutions can be used over and over again. Patterns name, demarcate and identify key aspects of a general solution structure. Patterns also form the dictionary of solutions to a certain problem area and allow two specialists in that field to name typical solutions and understand each other without explaining the core of solutions.

The refactoring of an object-oriented code has proved to be an efficient means of solving tasks of program evolution and support. However, presently there are practically no studies dealing with refactoring at a higher level of abstraction – the level of software architecture. Correspondingly, the transfer of this methodology to a higher level of abstraction is interesting.

Functionality of Identity & Access Management Systems

In their nature, IAM systems appear as an in-house or external single data storage about users. Their major objective is to ensure that data accounts granting the necessary rights appear in all the applications required by the user (preferably there should be one single account for all the applications).

Here is what this process looks like:

A request is compiled in the system regarding the necessity of granting a certain group rights (possibly, by means of acquiring data on regular operations from a corresponding system)

The request is confirmed with all responsible persons including specialists capable of assessing the consequences of such an access

When confirmed, this request is broadcast into instructions and is to be executed by system administrators

System administrators carry out all the necessary settings

The system controls the faultlessness of these settings, their completeness and sufficiency

The instructions may be carried out in the automated mode.

In order to allow the user to remember only one data account Identity Management systems are integrated with Access Control Management and Single Sign-On solutions.

Allowing the user to authenticate themselves in all the applications with the help of one set of credentials presents significant challenges, because applied systems support a limited and often non-crossing set of authentication methods. Moreover, the credentials format in various systems may not coincide (from the banned use of certain symbols up to problems with coding).

The accomplishment of this task requires:

  • specialized agents to which the application can delegate authentication functions (under the condition that the application is capable of actually delegating this function);
  • intermediary authentication servers to convert credentials from one format into another.

Among the chief parameters characterizing IAM-systems are:

  • document management properties
  • flexible use and application for organizations with their own traditions
  • the possibility of integration with existing document management systems
  • the possibility of applying the electronic digital signature

in the compilation and approval of requests

  • a list of supervised platforms and applications including requested rates of creating new agents for new platforms
  • accounting system development.

Changing Software Architecture and Refactoring

skypeRecently a tendency has arisen towards lifecycle growth of successful program projects. As a result, the volume of the ancestral code supported by the community of developers also grows. This fact helps explain the exceptional importance of tasks related to facilitating the development of the existing program code. At the same time, these tasks receive little attention from the scientific community and tool developers. As a result, contemporary methodologies overestimate the significance of the initial stage of a program system’s life cycle and practically neglect its further evolution. Therefore, there is currently an apparent lack of methodologies and efficient tools for supporting work with a corresponding code.

The situation changes when the question of how transformations can be used systemically as a centrally organizing principle in the process of the development and support of the existing software arises. However, the majority of researchers study transformations at a very narrow angle: as transformations at the level of the initial code, refactoring. Meanwhile, there are practically no studies dealing with transformations at a higher level of abstraction, i.e. at the level of software architecture. At the same time, many scenarios of the support and development of the existing code presuppose a change in the architecture of the existing system. Therefore, the development of the methodology and supporting tools aimed at the organization of a foreseeable and manageable process of changing software architecture is very interesting.

See Softage case study on phone number recognizer refactoring here: Phone Number Recognizer refactoring

Decentralized Planning

Division managers need to carry out planning in a specialized environment tailored to suit their personal needs and requirements. For instance, one particular manager might want to view only those expense departments and cost centers with which he is working, and not the entirety of the information held on the divisions. Since the majority of solutions give no opportunity for decentralized planning, many organizations use MS Excel. However, if every manager were to draw up an Excel-budget, the organization would have a number of budgets, each of which would be performed in its format and compiled according to its criteria. As a result, the aggregation of data  would be an arduous, erroneous and time-consuming task.

The Budgeting and Planning product allows for decentralized planning enabling managers to create budgets in the most comfortable environment. The user creates an individual planning interface for data entry and access to it. At the same time, the information is stored on a centralized basis. In this case, there is no need for manual data consolidation.

General information and transaction data come from InfoCubes contained in the SAP Business Information Warehouse. Since this data can be easily integrated with general and transaction data in SAP R/3 CO-CCA, it is also possible to integrate a corresponding cost center, cost element and currency data from R/3 to SAP SEM.

For further information on similar solutions see Softage Case Study: Investment Planning Software

Microsoft Releases “Cloud” Office

microsoft-cloud officeOn June 7 Microsoft Corporation released an office web-application package Office Web Apps for its “cloud” file storage system SkyDrive.

Any user registered with Windows Live can create, edit and download their office documents in Office Web Apps. The program also supports the creation of Word documents, Excel tables, PowerPoint presentations and OneNote notes.

Web Office doesn’t just operate in Internet Explorer but in a number of other browsers. Documents can also be viewed through a browser on smartphones. In the future, Office Apps for Web will also have an embedded system for accessing Hotmail .

The new service is available to all residents of the USA, Great Britain, Canada and Ireland. People in other countries can also use it. For this they need to follow a special link. Moreover, Microsoft gives no guarantee so far that the program will work smoothly with other languages as different from English.

Microsoft Finds more than 30 Drawbacks in its Solutions

Microsoft Corporation prepared a new patch set for its software solutions which is to be released on Tuesday, June 8.ms security holes

The preliminary notice says that a total of 34 drawbacks were spotted. These faults were found in Windows OS and all supporting versions (including Windows 7), MS Office applications, Internet Explorer and the Windows SharePoint Services platform.

Microsoft intends to publish 10 security bulletins, three of which will contain descriptions of critically dangerous vulnerabilities, whereas other drawbacks were labeled as “significant”. Many of the spotted vulnerabilities can be used by hackers in order to get unauthorized access to a remote computer and insert  random malicious code.

The patches will also include a workaround for a vulnerability in IE spotted at the end of April. The problem is connected with the specifics of processing VBScript code and Windows help files (.hlp).

As usual, the updated version of the Malicious Software Removal Tool will arrive along with other updates, which will remove the most common malicious programs. The patches can be downloaded through Windows Update and Microsoft Update services and automated updating tools embedded in Windows.

Software Architecture and its Refactoring

Why change architecture?

The need to change corresponding software may arise in the process of solving a large number of tasks aimed at its modernization. Generally, changes in corresponding software may concern not only its code, but all the other artifacts connected with a transformed program system. One of the most significant issues in this respect is the change of program system architecture. The following scenarios requiring a change in the existing software architecture may serve as valid examples here:

- Transformations determined by functional changes of software. It is desirable that the implementation of the new functionality does not alter the existing system logic. It is also important that the complexity of the implementation of the new functionality into the existing system does not significantly exceed the complexity of the realization of this functionality within a new project. Good architecture makes it possible to reach the goals set. Therefore, changing the corresponding architecture is a good step forward towards the implementation of the new functionality which also simplifies further system evolution.

- Change of software platform. It is highly desirable that the change of software platform may have the smallest possible effect on the existing code; it should only involve changes in the narrow platform-dependant system layer. The separation of this layer is an architecture task. Its solution is always connected with the necessity of architecture change.

- Transformations caused by the reorganization of the company which carries out the development. Outsourcing is a very good example of such reorganization. The solution to use outsourcing is a typical step taken towards the optimization of production. Unfortunately, this step is often made difficult by the problem of separation and transfer of components for external development. Changing program system architecture makes it possible to ease the solution of this task.

This list of scenarios leading to the necessity of changing software architecture is not complete: the examples mentioned above are merely to demonstrate the large range of tasks which require such changes.

Differences between Architecture and Classical Refactoring

code refactoringWhen refactoring methodology is transferred to the architecture layer, there are a number of specific features which determine the change of method characteristics:

Objects. While making a transition from classic to architecture refactoring, the objects on which the operations are performed also undergo certain changes. In classic refactoring, such elements as class and class instance are among the entities to be worked on. Architecture refactoring is applied for systems and components. Different types of connections which emerge between objects are also distinguished in various refactoring types.

Scope of changes. Classic refactoring is applied exceptionally in lesser scale. Usually, the consequences of the application of a separate classic refactoring pattern are limited to several files. Architecture refactoring patters are applied to architecture components. As these patterns are projected backwards from the structural model level to a program code, the changes may cover a significantly greater size of the existing code. 

Description of changes. Methods of classic refactoring can be illustrated with static models of language and code fragments. It is more convenient to use specialized structural models and tools which support reverse engineering for the description of architecture refactoring.

Testing. Transformations are considered correct if they don’t cause the change in the general “behavior” of a program system. The availability of a sufficient number of unit tests allows for the verification of the correctness of transformation. This makes unit testing one of the key aspects of classic refactoring. Architecture refactoring is also faced with the task of automated verification of the correctness of transformations. Unit tests allow the developer to be assured the changes are correct even when architecture refactoring is applied. At the same time, it is presently unclear how effectively unit testing works with architecture refactoring methods. In fact, this is determined by the difference in the scope of changes at classic and architecture refactoring.