Background Object oriented software development traces back to research performed at the Norwegian Computing Center in the early 1960s (Dahl, 1971). The methodology has been made popular largely by the evolution of powerful languages like Smalltalk in the 70's, C++, Delphi and Java in the 1990's and later VB.Net and C# in the 21st century. Today it is seen by experts in the industry as arguably the most efficient technique for producing robust software meeting the requirements of the users in acceptable timeframes (Montrose, 2010; Wang, 1996). During the design stage, how to map the characteristics of the system into a set of software objects is by no means a trivial task. The programming team must decide what relevant classes to include, what each of them should be responsible for and how they interact.
All of this requires a very careful analysis of the real world situation that is to be abstracted into computer software. Business process modeling takes what can be described as an action centred approach to system analysis. Focus is on what is done by whom, when and how it is done (Zhao, 2010) with the aid of a number of tools such as use cases. This article will present and evaluate the pros and cons of this type of business modeling as a vehicle for object oriented development and some of the most prevalent alternatives. Business process modeling One of the most critical phases of software production is to make sure that the requirements of the system are completely understood (Boehm, 1981). In other words, there should be no doubt what it should be able to do and how and all this should be clearly defined and gathered in a set of design documents.
They ultimately define the contract between the user and the developer. One of the most ubiquitous ways of obtaining this comes from the application of use cases, i.e. a number of defined sequences of action starting with an action from a user and ending with some kind of response back to this individual (van den Berg, 1999). Business Process modeling is about designing an IT system that support what people do rather than having people do what the system demands of them.
It is concerned with how a business carries out its activities in the most efficient manner and how to enable the members of the staff to achieve this (Turbit, 2005). As such, the system places the users of the software at the center of the analysis aiming to realize satisfaction of the end users needs. This emphasis makes the model very rewrding since misunderstanding can be easily identified and dealt with. Although Business Process modeling may share aspects of use case modeling, it remains totally distinct form use case modeling. Another crucial advantage of business process modeling is that it lends itself extremely well to the creation of classes.
The usage of entities for controlling the flow of data can very often be translated directly into a set of classes necessary for handling the tasks in the model. One author describes a similar technique as who what where schemes where the whos are obvious candidates to be modeled as classes in the object oriented system (Hristova, 2008). Drawbacks The heavy emphasis on documentation might not go well with all kinds of customers. Remember that every single aspect of the system will generate a use case with a graphical diagram and narrative plus other non-functional specifications.
This is good for clarity but it might be hard to get through the often very cumbersome and sizeable software documents.Another very important aspect is the delay from gleaning of requirements to coding and testing. Time spent in business process modeling means that the interaction with the customer in the first phase focuses on getting the use cases right so it is in a sense a "waterfall" method with analysis preceding design while implementation, testing and debugging comes at the latter stages. The creation of clear documents of the business process under consideration serves to vastly reduce the risk of mistakes with requirements gathering, though. When seeing this from the viewpoint of the developer, I must admit that I feel a little ambiguous on whether to bring in the "full cavalry" with UML or just do a simpler requirements document and go to coding. A major project with many team members might be easier to control with business process modeling while a small piece of software where they can be more rapidly produced with an agile sequence.
Alternatives I think that very few people in the industry would argue for using old school structured analysis and design methods. UML has grown into a de facto standard for the full development process and as such enjoys the advantage of being easily initiated in a larger team. Most of the members are likely to know it and have worked with it. Competition comes from what is known as "agile" development techniques. This is a family of methodologies sharing the focus on iterative analysis, implementation aand testing.
A prototype where some parts of the product can be tested should be created as soon as possible and tested with a number of test scripts. The result of the tests resembles the creation of use cases but now the errors can be corrected directly and eventually incorporated as real code rather than design documents. The risks of doing this appear to be that there is less overview of the system and that the requirements are not clearly defined. However the promise of more rapid development has drawn a lot of projects to this kind of approach lately.
The most well known are SCRUM and Extreme Programming. The latter defines a comprehensive set of rules for testing, code sharing and even implementation in pairs of developers working together for higher speed and accuracy. It has been linked by some to the trend for open source and transparent operating systems as well. It is estimated that the share of agile projects is higher on Linux platforms than Microsoft Windows family systems. ConclusionsIndeed, business process modeling simply provides users with a set of instruction that they can use to perform various faction in the most effective manna possible. By making the instructions fixed and repetitive, this modeling process enable the users to be come more efficient as they continue using the system and get accustomed to it.
Just like every new innovation overcomes the shortcoming of the previous innovations, the shortcomings of the previous programming techniques were certainly overcome with the development of the business process modeling. Evidently, object oriented programming techniques evolved as a remedy to some of the shortcomings and concerns on the previous modeling techniques and have been the prevalent paradigm for a number of years. However, there is still a raging debate on what type of method to use for the analysis process in the earlier stages. Business process modeling has achieved a great popularity but is it the most efficient way to do it? My opinion is that UML is best suited for the creation of large systems where clarity and consistency assumes great importance.
For middle and small type systems the overhead might be too costly and a less formal approach a better choice. Of special interest are the agile and iterative development cycles for object oriented systems gaining more and more followers and now posing a live and real threat to the status of business process modeling as the industry standard. One can imagine a number of different scenarios for software development life-cycles in the future.
