Software engineering principles

Chapter 1

“Software is a great combination between artistry and engineering. When you finally get done and get to appreciate what you have done it is like a part of yourself that you’ve put together. I think a lot of the people here feel that way.”

Introduction

This report discusses Software Engineering principles in context with Service-Oriented applications. Software Engineering covers a very vast area. It encourages the development of high quality and sustainable software,using quality software engineering tools and techniques. Service Orientation on the other hand is a trend in Software Engineering, it’s an approach, a way of thinking, a value system that promotes the construction of applications based on activities called services.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

It was very complicated to conclude the basic principles of Software Engineering and then to make a decision which of these principles are applicable and which are not applicable to the development of Service Oriented Applications. There exists so much information on Software Engineering and Service-Oriented applications but very few talks about the Software Engineering principles and their relation with SOA. However, after browsing through the internet and digging into many Software Engineering and SOA books and journals some conclusion is made which is described in detail in following pages. Like most of the researches, this research also takes into consideration few assumptions which are stated clearly.

Chapter 2

In order to be acquainted with the principles of Software Engineering it is essential to have a brief idea about it. The paragraph below will assist in giving some idea about Software Engineering.

About Software Engineering.

As mentioned above Software Engineering covers a very huge part in a development of any software. It is not a complex approach but over the years everyone has presented a different definition for Software Engineering because of its diversity. To get the more precise and clear picture, a few definitions from different sources are presented below.

• “The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines” [Bauer 1972].
• Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.” [CMU/SEI-90-TR-003]
• “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software” [IEEE 1990].

There are aspects of each of these definitions that have a say to the viewpoint of software engineering used in the construction of this report. One particularly important aspect is that software engineering builds on computer science and mathematics.

Software engineering encompasses a process, the management of activities, technical methods, and use of tools to develop high-quality, systematic, controlled, and efficient software products. Software is engineered by applying three discrete phases’ definition, development, and support. Subsequently, there are significant emphasis on analysis and evaluation, specification, design, and evolution of software. In accumulation, there are issues related to management and quality, to novelty and creativity, to standards, to individual skills, and to teamwork and professional practice that play a vital role in software engineering.

Chapter 3

“Service Orientation is a trend in software engineering that promotes the construction of application based on entities called services” [9].

Service-Oriented Architecture

A service-oriented architecture is the organizational and technical framework that enables an enterprise to deliver self-describing, platform-independent business functionality and make it available as building blocks of current and future applications. Simply speaking, in an SOA, a business is viewed as a portfolio of services that can be delivered independently and recombined without requiring detailed knowledge of how that service is implemented. [8]

According to Wikipedia, incomputing,service-oriented architecture(SOA) has different non-standard and openly-debated definitions. Basically, it is an attempt to provide set of principles or governing concepts used during phases ofsystems developmentandintegration. Such architecture is supposed to package functionality asinteroperableservices within the context of variousbusiness domainsinvolved. Several departments within a company or different organizations may integrate or use such services — software modules provided as a service — even if their respectiveclientsystems are substantially different. It is an attempt to develop yet another means for software module integration. Rather than defining anAPI, SOA defines the interface in terms of protocols and functionality. Anendpointis the entry point to such an SOA implementation.

Chapter 4

Principles of Software Engineering

A set of fundamental principles can act as an enabler in the establishment of a discipline; however, software engineering still lacks a set of universally recognized fundamental principles. A fundamental principle is less specific and more enduring than methodologies and techniques. It should be phrased to withstand the test of time. It should not contradict a more general engineering principle and should have some correspondence with “best practice”. It should be precise enough to be capable of support and contradiction and should not conceal a trade off. It should also relate to one or more computer science or engineering concepts. [1]

Principles are common and conceptual statements describing desirable properties of software products and processes. Principles become practice through methods and techniques, often methods and techniques are packaged in a methodology. Methodologies can be enforced by tools.

Principles of Software Engineering have a good impact on the process of software engineering and also on the final product. These principles facilitate to develop software in such a manner that it posses all the qualities like: efficiency, functionality, adaptability, maintainability, and usability. Principles are general, abstract statements describing desirable properties of software processes and products. The principles are applicable throughout the lifecycle of the software. Principles are the set of statements which describe the advantageous features of the product and process. Focus on both process and product is needed to deliver software systems. These principles help in controlling process which in turn helps to control the quality of the product. Only the control of process will not guarantee a quality product therefore it is important to concentrate on both process and quality.

As said earlier there are no fundamentally recognized principles of Software Engineering but we can list down few that may be used in all phases of software development.

• Rigor and formality
• Separation of concerns
• Modularity and decomposition
• Abstraction
• Anticipation of change
• Generality
• Incremental Development
• Reliability

Principles explained.

Rigor and formality

Webster defines Rigor as.

• harsh inflexibility in opinion, temper, or judgment : severity
• the quality of being unyielding or inflexible : strictness
• severity of life : austerity b: an act or instance of strictness, severity, or cruelty 2: a tremor caused by a chill 3: a condition that makes life difficult, challenging, or uncomfortable; especially : extremity of cold
• strict precision : exactness

Webster defines Rigor as “harsh inflexibility in opinion”, but that’s not the general meaning of rigor in project management. In general Rigor means the strict precision with which you follow some project management belief or practice. Advancements of this approach enable us to construct more consistent product, organize their cost, and boost our confidence in their reliability. Formality is a stronger requisite than rigor; it requires the software process to be driven and evaluated by mathematical laws.

As it is seen that Software engineering is a very imaginative design activity, so it must be practiced systematically. Rigor is an essential match to imagination that increases our confidence in our developments. Formality is rigor at the highest degree. Software development can accept neither ambiguity nor inaccuracy. Where rigidness helps to produce consistent products, controlling cost and increases discretion in products, Formality checks the process of software production using mathematical laws.

Rigor and formality in context with SOA

SOA aims to improve flexibility. The key reason for using SOA is that it should help you in your business. For example, you may need IT solutions that store and manage your data, and allow you to automate the usual processes that deal with this data. A critical factor for business success these days is keeping time to market share. To deliver a quality solution right on time, you need flexibility. But flexibility has a lot to do with clear organization, roles, processes, and so on. Therefore, SOA has to deal with all these aspects. [10]

Conclusion

For Software Engineering, Rigor means the strict precision with which you follow some project management belief or practice. On the other hand SOA follows agile methodology which can be described as “iterative” and “incremental. As SOA is intended to enable flexibility, adaptability and reusability, this principle is not applicable to SOA.

Separation of concerns

There is a very popular saying “Divide and conquer”, it holds good in software development process also. This principle teaches to first divide or break the problem into small and different modules. This helps in dealing with different individual aspects of a problem and we can concentrate on each part separately. A problem can be divided with respect to time, quality, complexity etc. Once the problem is divided into pieces a project leader can thus easily separate the responsibilities among the developers. By doing this development of a big part of the project can be done in parallel, thus saving time.

Separation of concerns in context with SOA

SOA is all about services. SOA is nothing without services. Services are primary assets of SOA. “… Services in SOA are modules of business or application functionality with exposed interfaces that are invoked by messages from service consumers.” [11].

Conclusion

In SOA, complex problems are divided into different modules to design various reusable and interoperable services. Thus this principle does applicable to SOA.

Modularity and decomposition

Modularity is a kind of Separation of concerns. A complex problem can be divided into simpler parts called modules, allowing details of each module being handled in isolation and separately. A system that is collected of modules is called modular. When dealing with different modules we can ignore details of some not so important modules. Each separated module should be highly interconnected with the rest of the modules so that each module should be understandable as a meaningful unit. Components of a each module should be closely related to one another. Modules should exhibit low coupling means they should have low interactions with other modules. Too much interaction with other modules makes a module dependent on other, thus making it less reusable.

Modularity in context with SOA

“Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.” [12]

Conclusion

‘Loose Coupling’ is one of the basic principles of SOA. The principle of Service Loose Coupling promotes the independent design and evolution of a service’s logic and implementation while still guaranteeing baseline interoperability with consumers that have come to rely on the service’s capabilities [12]. This principle does applicable to SOA.

Abstraction

A software developer cannot deal with more than a few concepts and their relationships simultaneously. An abstraction allows suppressing details that are unimportant to him/her and emphasize the important information [2]. Abstraction helps manage the intellectual complexity of software [3]. Abstracting means that a higher-level concept disregards certain properties altogether [4, 5].

Abstraction is also related to Separation of Concerns. Here the modules are separated on the basis of purpose of the module. Actually we separate what from how. Then we can easily make out the central aspects of a phenomenon and overlook its details. Abstraction is the only tool through which we can actually master the complexity of the problem. Abstraction depends on the functionality of the module (What) or point of view. To decide which type of abstraction is to apply mainly depends on the purpose of the particular problem.

Abstraction in context with SOA

“Service contracts only contain essential information and information about services is limited to what is published in service contracts.” [12]

Conclusion

Abstraction ties into many aspects of service-orientation. On a fundamental level, this principle emphasizes the need to hide as much of the underlying details of a service as possible. Doing so directly enables and preserves the previously described loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. [12]. This principle does applicable to SOA.

Anticipation of change

The only constant is change. Change is everywhere. Even in Software development change always happens. It is very important to identify any likely change in the early phase of software development. When expected changes are recognized, a particular care must be taken to progress in a way that will make future changes easy to apply.

The changes occur because usually the entire software requirement is not understood by the development team and this happens because of the communication gap between client and software team. Also most of the times the users and the environment of the requirement changes which leads to the minor and some time even major changes in the application. Such major changes affect the supervision of the software process. A small change in the application pushes the finished product back into the software development life cycle. It becomes necessary to do a regression testing with maintenance. Maintenance is the process where modifications are done to the application to reflect the changing requirements.

Anticipation of change in context with SOA

Conclusion

Generality

Generality can be characterized as a state or quality of being not limited to one particular case. Generalisation, as an inductive process, collects information about a number of particulars and presents it in a single description [6]. General description collects a set of individuals according to the features that are applicable to the whole as well as to every member of a set. As noted in Navrat [5], generalisation moves things along the set-superset relation. Specialization, as an opposite operation, moves things in set-subset relation. Less general description determines a smaller set of things, while its transformation to a more general description will determine a superset of the original set. Every member of less general set is a member of more general superset.

While breaking a big problem into small modules one should generalize the problem to make the solution more potential for being reused. But a careful balance between performance and cost is necessary while generalizing a problem. Generalization often helps in solving some special case easily.

Incremental Development

“Keep developing until you get it right”. Incremental development is based on agile methodology. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. [7]

Incremental development means development in a stepwise fashion. According to this principle a subset of the system is delivered early to get the feedback from the users in the early stages of the development. New features or changes , if any, can thus be added incrementally during the early stages without doing much of changes in the structure of the system. It focuses first, more on the functionality, then turn to performance. It is a step-wise process which makes closer approximations to reach a desired goal. But a closer and careful management interference and documentation is necessary during all the steps.

Incremental Development in context with SOA.

As stated earlier, SOA is based on agile methodology. A disciplined Agile software development definition can be “An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely mannerwhich meets the changing needs of its stakeholders.” [13]

Conclusion

Reliability

According to ANSI, Software Reliability is defined as: the probability of failure-free software operation for a specified period of time in a specified environment.[ANSI91][Lyu95].

The NASA Software Assurance Standard, NASA-STD-8739.8, defines software reliability as a discipline of software assurance that:

• Defines the requirements for software controlled system fault/failure detection, isolation, and recovery;
• Reviews the software development processes and products for software error prevention and/or reduced functionality states; and,
• Defines the process for measuring and analyzing defects and defines/derives the reliability and maintainability factors.

Reliability in context of SOA

For services to carry out their capabilities consistently and reliably, their underlying solution logic needs to have a significant degree of control over its environment and resources. The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioural predictability. [12]

Conclusion

Principle of Autonomy is one of the principles of SOA which talks about the reliability and behavioural predictability. This principle does applicable to SOA.

References

• Abstracts from Fundamentals of Software Engineering, Second Edition, by Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli.
• Krueger, Ch. W., 1992. Software Reuse. ACM Computing Surveys, 24: 131-83.
• Pree, W., 1994. Design Patterns for Object-Oriented Software Development. Addison-Wesley.
• Návrat, P., 1994. Hierarchies of programming concepts. Abstraction, generality and beyond. ACM SIGCSE Bulletin, 26: 17-21, 28.
• Návrat, P., 1996. A Closer Look at Programming Expertise. Critical Survey of Some Methodological Issues. Information and Software Technol., 1: 37-46.
• Czarnecki, K. and U.W. Eisenecker, 2000. Generative Programming. Methods, Tools and Application. Addison Wesley.
• From Wikipedia, the free encyclopedia.
• Cartwright and Doernenburg 48 (3): 26. (2006)
• Zoran Stojanovic & Ajantha Dahanayake. Service-Oriented Software System Engineering, Challenges and Practices. 1
• Nicolai. M. Josuttis, 2007. SOA in practice. The art of distributed system design. 12-13.
• Eric A. Marks & Michael Bell, 2006. Service-Oriented Architecture, A Planning and Implementation Guide for Business and Technology. 33-34
• http://www.soaprinciples.com
• SOA: Principles of Service Design, byThomas Erl
• http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
• http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
• http://www.soaprinciples.com/service_autonomy.asp