Suitability of Extreme Programming and RUP Software Development Methodologies for SOA Applications

Guillermo A. Callahan 1

1 Seminar on Enterprise Information Systems : Service­Oriented Architecture and Software Engineering, Helsinki University of Technology ­ SoberIT, Innopoli 2, Tekniikantie 14,

02015 Espoo, Finland

gcallaha   @cc.hut.com   

Abstract.  Because   of   the   recent   importance   given   to   Service­Oriented Architecture (SOA), a document review investigation has taken place with the objective to compare SOA development with  two highly used agile software development   methods:   Extreme   Programming   (XP)   and   Relational   Unified Process   (RUP).  The  motor   behind   this   investigation   is   to   see   if   this     agile development methods are capable enough to design effectively and efficiently SOA­type applications.  The  investigation concluded that  both methodologies are not exactly suited to create SOA applications, but RUP has a greater chance to provide SOA­type  applications if the proper adjustments are made, specially on the design side of the methodology.

Keywords:  Service­Oriented   Architecture,   Software   Development   Methods, Extreme Programming, Relational Unified Process (RUP). 

1   Introduction

Service­Oriented Architecture has been a topic that has been discussed about a lot recently,   specially   because   of   the   supposed   benefits   it   can   provide   companies: empowering  a  business   environment  with   a   flexible   infrastructure   and  processing environment by provisioning independent, reusable, automated business processes and providing   a   robust   information   foundation   for   leveraging   these   services.   In   other words: “a software application that has the power to incorporate business services to  business practices all  together, while being distributed along a network, no mater  what is the underlying technology” [1]. Also these services are reusable, independent and   can   compose   aggregate   services   by   combining   it   with   other   ones,   therefore reducing the cost of new technology for every change made to the system, creation of new services, maintenance, etc. For this, SOA can be defined as the logical way to design  a software concept that provides services to either end­user applications or to other services distributed over network, via published and discoverable interfaces [2]. 

As new computing paradigm, SOA is in it's baby steps, as most of the structure, design and technology are still under research. But as an idea, it is not as new, this is because the vision of having reusable, composite and dependable code components, as well as the benefits, have long been envisioned [2].

One of the research priorities regarding SOA is the search of a proper design and development methodology that can take into account all of the SOA principles and that,  while  being  closely   followed,   can   conclude  on   the   creation  of  working  and efficient SOA­type applications.

Since SOA is of high importance for businesses (specially because the increasing importance of services in the economy of developed countries [3][4]), and fact that there  is  no proper development  methodology yet,  a  document­review investigation was carried out. The objective of this investigation is to find if any current software development methodology can “more or less” replicate, at least to some extension, SOA principles at the moment of design or development.

The methodologies chosen to take part in this investigation are two popular agile software  developing methodologies:  Extreme Programming (XP) and   the  Rational Unified Process   (RUP) [6].  These methodologies have  their  very own differences, strengths, drawbacks, etc. Even though, RUP is sometimes not considered an “agile” development method,  because of   the  large quantity of   requirements  and processes between   iterations,   but   still,   the   methodology   can   be   tuned   to   be   “agile”   by eliminating some processes between iterations. even though, it is also because of the large   differences   between   XP   and   this   methodology   that   it   was   chosen   for   this investigation; after all they still carry out the same objective: that at the end of the development process, the software product should be finished, or at least the reasons for why the development couldn't continue are explicitly given.

The rest of the document is written in the following way: each of the previously stated methodologies will be explained separately, mentioning their characteristics, it's life cycle and it's principles, then it's benefits when developing SOA­type applications, it's   drawbacks   after   that,   and   possible   point's   of   improving   when   using   that methodology when developing SOA­type applications.   

2   Extreme Programming (XP):

Extreme Programming (XP) is a relatively new agile software development method, that, evolving from the problems cause by the long development cycles of traditional development practices [7], the methodology concluded as a combination of practices that have been found effective in software development processes over time. These principles, even though not new, were incorporated in such a way that they are lined up   to   function   with   each   other,   eventually   forming   this   methodology.   The   term “Extreme” comes from taking these principles to extreme levels [8] .

The methodology is considered as an agile software development method because: it is an incremental development methodology (that takes out small software releases, versions or parts of a software product in rapid cycles), it's cooperative nature with 

costumers (costumers and developers in close communication), straightforward (as in the method itself is easy to learn, modify, etc) and that it's adaptive (it is able to make last minute changes to the software product) [8]. 

The life cycle of the XP software development methodology consists of 6 steps or phases, which are [6]:

− Exploration:  This   is   the   first  phase,  consists   that   the  costumer  writes  “story cards” (description of features to be added into the program), which are delivered to   the   developers,   where   afterwards,   these   familiarize   themselves   with   the requirements, the technology, the practices they are going to be used, etc. After that, the team of developers test the technology and also the development of a prototype to explore the architecture possibilities. 

− Planning:  Here   the  development   team sets  priority   to   the   “story   cards”   and agrees with  the costumer about  the contents  of   the first  release,  and also  the schedule for each of the features.

− Iterations to release: The schedule set in the planning phase is broken down to a number of iterations, these iterations create one or more functions of the system in each one of them. Functional tests are made after every iteration and at the final iteration, the system is ready for production. 

− Productionizing:  This phase consists of extra testing and performance checks, while  also revising  if  new changes are  found and need  to  be   included  in   the current release, this of course to provide a much better version for the costumer.

− Maintenance:  The   development   is   in   this   phase   after   the   first   version   is productionalized  and   the  XP project   is   kept   in   the  production   running  while making new iterations.  

− Death: It is the final phase, when the costumer doesn't have any more story cards to provide and it satisfies the costumers needs in every aspect. Also this is the phase where the documentation is written since there are no more changes to the architecture.  This   is   also  when   either   the   system  becomes   too   expensive   for further  development,  or   it's   canceled  when  it   doesn't  get   to  meet   the  needed requirements.

The   methodology   claims   to   be   able   to   provide   successful   software   development despite having a vague idea of the environment (filled with uncertainty), or being in an   environment   that   has   constant   changes.   The   methodology   aims   to   provide   a successful developing if the following practices are being followed [8]:

− Planning   Game:  The   programmers   estimate   the   effort   needed   for   the implementation of the customer's stories, while the customer decides the scope and timing.

− Small/Short Releases:  A simple system is “productionized” rapidly – at  least once every 2 or 3 months.

− Metaphor:  This means that  both the customer and the programmers “share a story”   based   on   metaphors   that   guides   all   development   by   describing   the functionality of the system.

− Simple   Design:  Emphasis   on   finding   the   simplest   possible   solution   that   is implementable at the moment.

− Testing: The software development is test­driven. − Refactoring:  It   means   restructuring   the   system   by   removing   duplication, 

improving communication, simplifying and adding flexibility.− Pair Programming: Two people write code in the same computer.− Collective Ownership: Anyone can change code at any given time.− Continuous Integration: A new piece of code is integrated into the code­base as 

soon. − 40­Hour Week: Maximum of a 40­hour working week, with no more than two 

overtime weeks in a row are allowed.− On­Site Costumer:  The customer has to be present and available full­time for 

the team.− Coding Standards: Coding rules exist and are followed by the programmers.− Open Workspace:  A large room with small cubicles where pair programming 

can be performed.− Just   Rules:  The   team  has   it's   own   rules   that   are   followed,  but   they   can   be 

changed at anytime.

In   simpler  words,   the  methodology  consists  on  keeping   the   “agile  methodology” requirements  by   having   small   groups   of   tightly   communicated   developing   teams, which   develop   small   parts   of   the   project   in   quick   intervals,   where   the   costumer interacts   directly   to   the   team   to   see   the   small,   but   (supposedly)   increasing improvements   in   the  development.   It   is  based  on  high  communication  within   the development team and the costumer, simple solutions by small iterations and quick feedback to stop any chance of creating complicated code that won't be used or that has flaws in it,  and finally the courage to try, day by day, small changes to the code to get to the best solution, providing an evolving design at “the moment of coding”.

2.1 Comparison of XP with SOA ­ Benefits:

SOA indeed requires an evolving software development method, since SOA consists of a highly uncertain environment where constant business, protocol, code, process among   other   changes   are   already   considered   and   foreseen.   Since   XP   considers changes after every small and   rapid iteration, it allows for quick changes inside the code, providing a flexible coding environment. 

The instant communication with the costumer is also a great strength for the SOA environment, since business rules and processes are constantly changing and adding up to the original project.  Direct  communication with the costumer can provide a 

more   accurate   description   of   the   business   needs   and   requirements   the   costumer desires in the project.

Another   strength   of   XP   inside   the   developing   of   a   SOA   is   that   the   high communication   between   developers;   small   teams   constantly   communicating,   well defined   roles   and   pair   programming   seem   to   provide   large   improvements   in productivity and in obtaining a successful final project.

2.2 Comparison of XP with SOA – Drawbacks:

There   are   many   publications   that   argue   that   XP   is   not   really   a   good   software development methodology, as they argue that the lack of documentation (either on requirements or design), constant code tweaking and unlikeliness of having either a capable on­site costumer, or one that is available anytime, provides difficulties for the development of a software project. Even though a software project can be finalized using XP, same publications argue that other development methods can do the same more effectively, cheaply and easily [9][10].

On   the   side   of   developing   SOA   applications   with   XP,   the   most   important drawback is the lack of any  up­front design of the system or of its requirements. The immense requirements of a true SOA inside a business structure can cause loss of focus; producing bugs and an architecture that can be completely wrong design­wise. The   development   of   an   architecture   that   uses   services   as   building   blocks,   that incorporates these services themselves to use them to create composite services, that has   to   support   constant   changes   in   the   business   environment   with   an   increasing amount   of   possible   variables   inside   it   and,   most   importantly,   the   need   for   these services to work correctly in any situation requires a well thought design beforehand, one that incorporates all the possible variables inside the development. Secondly, as SOA tries to incorporate services from previously designed applications and systems, keeping track of the state of the current applications and keeping a tangible reference or  model  of  development  could be very useful   for   the effective development of  a SOA­driven architecture. All of  this without mentioning the possibility of creating composite services out of single services, and that these compositions can act as a service themselves, or not mentioning the management required behind these services so they can operate seamlessly and effectively [1][9][10].

The   lack  of  documentation,  or   any  design  model,   is   supposedly   replaced  by constant  testing, pair  programming and  the availability  of  an an on­site  costumer. Constant   testing might  be  able  to  detect  bugs,  but  sometimes  failure  in  design  is detected very long afterward. Pair programming can be useful for any development process, but  the need for an specification is still  required, even though the on­site costumer can be able to provide the necessary insight, the fact that the possibility of a completely aware costumer of   the business situation inside the company,   and the (assuming) slight chances of being available all the time, requires the need of an up­front documentation to guide the developers through the process [9].

Another possible drawbacks when applying XP is that if either the size of the developing   team   (as   it   is   best   suited   for   small­medium   teams),   the   geographical circumstances (as it is stated that geographically separated teams are intolerable for 

XP), the business culture behind the costumer (as, for example, rigid schedules from the   on­site   costumer   stops   the   feedback   from   being   delivered,   slowing   the development process) and finally, the type of technology (if it requires long feedback times and a strong resistance to change, which is a possibility behind SOA) are not equivalent   to   the  XP principles,   it  makes  XP unsuitable   for   the   software  project, which can include SOA­related projects [1][9].

2.3   Discussion   of   Areas   of   Improvement   for   the   Development   of   SOA­Type Software (XP):

Since XP is one of the most documented agile software development methodologies, there's been reports on the possibilities and restrictions of XP, as for example, there are statements of productivity gains by using XP inside a e­business company.   The company   in   question,   did   server­side   Java   development   and   the   company   used principles similar to the one XP advocates, and it showed increases in productivity. But   still,   even   though   that   positive   review,   it   is   still   hard   to   conceive   the implementation of XP in a SOA­related development [11]

The lack of a real up­front documentation can be seen as a big flaw for SOA development.   As   stated   before,   the   huge   requirements   and   variables   inside   SOA applications   should   require   a   “starting   point”,   (which   stops   ad­hoc   development, mainly because of the use of previously developed applications). The use of at least some documentation should be of very big use for SOA development.

It is stated that XP is just a group of principles, and also, it has been noted that not all of the investigations regarding developing experience with XP have used all of the principles. This indicates that using XP for SOA can be tailored a bit to choose the principles that can work best in the developing of this architecture [8].

Definitely, as stated before, documentation is needed. But the adaptation of this principles   to  include bigger  and geographically separated groups could also be of great use, as there are statements that SOA is a multi­disciplinary task, which will require   large   amounts   of   people   in   planning   and   possibly,   also   in   development. Another point of improvement could be the fact of having roles that involve costumer relationships, designing responsibilities, managerial responsibilities, and also, a role that   involves knowledge or  research of  the possible costumers  that  would use this SOA­based application, as these would be most likely required for the development of an effective SOA project.

In a personal opinion, I believe XP is more concentrated on small projects filled with high uncertainty. Even though SOA is in a highly uncertain environment, it is by no   means   small,   which   requires   adapting   this   methodology   to   support   the development   of   this   type   of   applications.   Even   though   it   also   seems   that   XP   is concentrated   more   on   the   programmers   than   on   the   clients,   this   should   also   be adapted to SOA, as SOA is firmly concentrated on providing better services easily to an end­user that most likely, won't be the developer's costumer.

In   conclusion,   although   XP   seems   to   provide   results   productivity­wise,   the adaptation to SOA development (in theory)  would require changing many of it's main 

principles so the development of this kind of applications can be effective (providing an operable SOA) and efficient (faster and with less problems while developing).

3 Relational Unified Process (RUP):

The Relational Unified Process is an “agile” software development method created by Philippe Kruchten, Ivar Jacobsen and others at Rational Corporation to complement the Unified Modifying Language (UML – an industry­standard modeling method). Even though the methodology is mostly focused on the object­oriented paradigm, it does not implicitly rule out the other methodologies for designing software [13]

As   stated   previously,   this   software   development   methodology   is   considered “agile”   as   it   is   able   to   comply   with   all   the   requirements   needed   for   an   agile methodology (adaptive, straightforward, incremental and cooperative) many believe that this method is too robust to be called agile, as it has various design phases and it takes too long to provide a final version. But, as this is also a step of rules and best practices,   developers   can   get   to   choose   the   parts   they   believe   would   benefit   the development process [9].

The   RUP   development   process   consists   of   four   phases,   which   are   split   into (usually many) iterations, where each one of them has the purpose of producing a demonstrable part of the software project. The phases are [12]:

− Inception:  Here,   the  needs of  every stakeholder  are  taken  into account.  This helps   find   all   critical   use   cases,   candidate   architectures   for   the   system   are schemed and also estimations are provided.

− Elaboration: In this phase is where the foundation of the software architecture takes place. The architecture is elaborated with the output of the previous phase. The project plan is elaborated  while the process, infrastructure and development environment are identified. At the end of this phase, most use cases and actors are identified and described, the complete architecture is described and a prototype of it has been created.

− Construction:  In   the   construction   phase,   all   the   remaining   components   and applications are developed, integrated into the product and are tested.

− Transition:  The   process   concludes   with   this   phase,   which   is   essentially   the release of the product. And also, according to user response, modifications and the addition of extra features takes place as well as the writing of manuals and such.

What it is to note, is that through all these phases, there are nine work flows that are parallel to the phase. In each iteration, usually in extensive manner, all this work flows are addressed. The work flows are:  business modeling, requirements,  analysis and  design,   implementation,   test,   configuration   and   change   management,   project  management and environment [12].

The methodology consists essentially that in every phase of the development life cycle, each part of the development has to be consistent and done methodically, not 

escaping any detail or potential error. This, even though takes probably a lot of time, it provides software that is likely to be consistent with the previously stated model that, after a lot of time in it, contains all the necessary information to provide the costumer with the software applications he desires. To also help in the development process, the methodology follows the next practices [12]:

− Develop Software Iteratively:  Develop   the  software   in  small   increments  and short iterations to detect potential risks and problems early.

− Manage Requirements: Identify the most important requirements before coding; the ones that change over time and have the biggest impact. Among it's benefits are   detection   of   inconsistencies   and   improved   communication,   as   the requirements are clearly defined.

− Use Component­Based Architectures: Improved flexibility in development and also reduction in future development efforts are among the benefits of isolating code that will most likely change over time or that many resources share.

− Visually Model Software:  Using common visualizations, a clear and common language   is   established   among   the   developing   members.   Improving communication and common understanding. It also helps developers to not lose track of the project in the development process.

− Verify Software Quality:  By testing every iteration, defects and bugs can be detected even before the development cycle, reducing resources in maintenance.

− Control Changes to Software: All changes to requirements should be managed and  their effect  on software traced, as  this  improves  the understanding of  the current situation of the application.

As   a   summary,   RUP   consists   of   a   robust   methodology,   were   small   iterations, elaborate modeling sessions, constant testing and a common design language can be the better solution for creating software applications of great quality, error free and that meet all the costumer requirements.

3.1 Comparison of RUP with SOA ­ Benefits:

As it was compared previously when comparing SOA development necessities with XP, there is a need for proper documentation to keep track of all the requirements, changes, and possibilities when designing services, or SOA­type applications, and this is what RUP provides: a methodology that is mainly focused on initial requirements, modeling and documentation, while also keeping the “agile” software development method's principles.

Other   than   fact   of   providing   an   up­front   documentation,   where   states   the requirements and the most important areas of development; which are useful to state the situation where the company is, it's best practices, and how to provide a visual connection of all the services. Another big benefit of this methodology is that one of it's   practices   is   that   it   encourages   “component   based   architectures”.   This “components”   are   the   building   blocks   for   services,   which   means   that   this 

methodology is at least concerned on some of the key elements of SOA: re­usability, abstraction of  business processes,  flexibility,  and code that   is   loosely coupled and finely grained [1].

3.2 Comparison of RUP with SOA – Drawbacks:

The main drawbacks of using RUP to create SOA­type applications is the fact that RUP is mostly object­oriented (at least in design), which is not adequate for service modeling, as services include many other factors that object­oriented design leaves out.  A couple  of  examples  are   the  aggregation of   services   to  combine  composite services that can, act as a service themselves, also the fact that it ignores underlying infrastructure (protocols, location and technologies), service management, etc. [1][3]

Other visible drawback in applying RUP is the lack of agility (in comparison with other methodologies), as this methodology is far more robust and requires much more to do in every iteration than in other software developing methods. Even though, this may not be considered as significant drawback, sometimes a more agile model could be of use if the need for an SOA application is immediate.

Related to the last drawback, the fact that RUP doesn't have any real mention of how   to   adapt   the   methodology   to   a   software   project   while   considering   the circumstances of it and it's environment,   leaving this task up for the developers. In the case of  SOA, a rigid methodology would do more  than fine,  specially on the current situation of SOA applications, but in the near future, the rapid creation of such applications might be an increasing need that, unless having the proper combination of principles or an adequate adaptation to SOA, might stop developers from picking this methodology [6]. 

3.3   Discussion   of   Areas   of   Improvement   for   the   Development   of   SOA­Type Software (RUP):

The main area of improvement is the creation of a proper modeling technique that can be adequate  for   the creation SOA­type applications.  The combination of   the RUP principles,  with  a  proper  business  modeling   approach  would  provide  much better background for the development of these applications. It's also convenient to mention that this modeling technique should also consider the aspects mentioned previously, such as service composition, management, gap analysis, focus on service coupling, cohesion and granularity as design principles, service versioning and governance [1]. Also   the   creation   of   proper   tools   that   can   ease   the   development   of   SOA­type applications, specially one that can automatically analyze business processes in detail, discovering and selecting suitable  external  services,   interaction problem detection, alternative solution search, service monitoring, etc. In my opinion, this can help in the way UML tools help in RUP. 

4 Discussion:

As it can be seen in the discussion paragraphs, both software development method have   different   advantages,   disadvantages,   and   places   for   improvement   in   SOA software­specific development. The main requirements needed, in both methodologies include a moderate balance between quick iterations and no documentation or design, and between long iterations and large quantities of documentation, and as well the use of a Service Oriented design method. Currently,  there is no such thing as Service Oriented design method, but research is carried out [1]. 

It   is   also   up   to   discussion   the   possibilities   of     also   researching   an   specific software development method for SOA software. But the implementation of current software development methods seems to be more than adequate, considering it's large number of advantages, it's all about finding the proper best practices that can be well suited for SOA development, this of course takes research time, as well as practice from enterprises. 

There is no clear advantage, or any for that matter, that one of both Software development   methodologies   reviewed   in   this   article   are   better   for   SOA   software development,   they   seem,   in   this   case,   to   provide   different   types   of   advantages according to the type of  task (XP small software projects while  large RUP object oriented projects, both in uncertain environments). This can indicate that the proper combination   of   these   two   methodologies,   as   well   as   adding   a   service­oriented documentation/design   methodology,   can   be   enough   for   the   development   of   SOA software. It is my opinion that states that the use of RUP, for the design (using service oriented methodologies), development and maintenance of the main architecture of SOA   software,   while   using   XP   for   the   creation   and   composition   of   services,   is sufficient to provide the advantages of both methodologies, and would be enough to maintain all possible requirements in software development. 

5 Conclusions:

As it can be seen, both software development methods are quite different, but still carry out the same objectives either way. Anyway, for SOA software development, some analysis must be done to choose the proper  system for the development of such software   type.   A   table   comparing   both   methods,   as   well   as   SOA   software requirements is shown in Table 1.

Table 1.   Comparison of SOA Software Development with XP and RUP software development processes.  

Characteristic SOA XP RUPSize of development team

It is likely to require large multi­disciplinary teams.

Small tightly communicated teams

Large teams

Level of documentation

Extremely high considering legacy systems and requirements

None, all based on direct communication with a costumer.

High, all possible descriptions of the system 

developmentDevelopment time

Long, at least while designing the Architecture, but will be small when the architecture is in place.

Quick iterations for quick development

Long, but steady development

Type of software it's focused on.

Enterprise  Small, Costumer based Any size

Type of orientation

Service Any, no real methodology behind it

Object

As a  summary,  neither  XP or  RUP,   in   their  complete  extension,  are not  software development methods completely adequate for SOA software development, as there are characteristics  they miss  and can  take   into account   for  SOA software­specific development. Even though,  currently, there is no SOA specific development method, in my opinion,   the use of   the best  business  practices   from current  methodologies seems like the best bet for current SOA development. 

Finally,   Table   2,   summarizes   graphically   all   that   was   explained   in   the   previous sections.

Table 2.   Comparison of  XP and RUP software development processes, considering Advantages, Disadvantages, etc. 

Characteristic XP RUPAdvantages – Fast iterations and 

development.– Direct communication 

with the costumer.

– Consistent methodology.– Large amounts of design 

and preparation.– Focused on large projects.

Disadvantages – Does not consider any documentation.

– Focused at small projects. 

– Too robust and long development process and iterations.

– It mostly object­oriented.Possible changes to fit SOA.

– Slight use of a methodology  and design will be useful.

– Concentrate on the service creation side of SOA development.

– Considering bigger working groups

– Change the methodology and design features to a Service­Oriented one

– Concentrate on the Architecture development of SOA. 

References:

1. Papazoglou, Michael P., Traverso, P., et al.: Service­Oriented Computing Roadmap. Dagstuhl Seminar Proceedings. 005462. Service Oriented Computing (SOC). (2006).

2. Maceheiter,   N.,   Ward­Dutton   N.:   Real   SOA:   Critical   Success   Factors.   Macehiter Ward­Dutton. (2005). 

3. Hurtwitz,   J.,   Bloor   R.,   Baroudi   C.:   Service   Oriented   Architecture   for   Dummies. Willey Publishing Inc. (2006).

4. Chesbrough,   H.,     Spohner,   J.:   A   Research   Manifesto   For   Services   Science. Communications of the ACM. Vol.49, No.7. July (2006).

5. Sheehan, J.: Understanding Service Sector Innovation. Communications of the ACM. Vol.49, No.7. July (2006).

6. Abrahamsson,   P.,   Salo,  O.,  Ronkainen,   J.,  Warsta,   J.:Agile   software  development methods ­ Review and analysis. VTT Publications 478. Espoo, Finland. (2002).

7. Beck, K.: Embracing Change With Extreme Programming. IEEE Computer 32(10): 70–77. (1999).

8. Beck,   K.:     Extreme   programming   explained:   Embrace   change.   Reading,   Mass., Addison­Wesley. (1999).

9. Stephens,   M.:   The   Case   Against   Extreme   Programming. http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp.  August  26,   (2001). Last updated: January 26, (2003).   

10. Stephens, M., Rosenberg, D.: , Extreme Programming Re­factored: The Case Against XP, Apress,  (July, 2003).

11. Maurer,  F.   and   Martel,  S.:   On  the   Productivity   of   Agile  Software  Practices:  An Industrial Case Study. (2002).

12. Kruchten,   P.   :   The   Rational   Unified   Process:   an   Introduction.   Addison­Wesley. (2000).

13. Jacobsen,   I.,   Christerson,   M.,   Jonsson,   P.   and   Overgaard,   G.:   Object­Oriented Software   Engineering:   A   Use­Case­Driven   Approach.   Reading,   MA,   Addison­Wesley. (1994).