Service-Oriented Architecture is an architecture comprising loosely coupled services, ‎described by platform-agnostic interfaces that can be discovered and invoked dynamically. ‎

1. Service Oriented Unified Process
(SOUP)
Prepared By:
Hazim Alghalayini
Hazim.alghalayini@gmail.com
December 2013

2. Abstract
Despite recent reports that it has failed, the reality is that Service-Oriented Architecture (SOA)
remains the best option available for systems integration and leverage of legacy systems. The
technologies to implement SOA will certainly evolve to address emerging needs, but its concepts
will remain. To address those needs and concerns that SOA is potentially being stretched beyond
its limits, a significant and coordinated research program is needed.
Introduction
Service-Oriented Architecture is an architecture comprising loosely coupled services, described
by platform-agnostic interfaces that can be discovered and invoked dynamically. SOA represents
a paradigm shift in software engineering, where the key abstraction is that of services, utilized to
support rapid and low-cost application development through service composition. While
technology and standards, such as Web services, are important to achieve SOA, it has been
widely recognized that they are not sufficient on their own loosely coupled refers to defining
interfaces such that they are independent of each other’s implementation. In a loosely coupled
system, you should be able to swap-out one of the components and replace it with another and
cause no effect to the system, SOA projects potentially suffer from one or more of the following
problems:
 SOA projects are significantly more complex than typical software projects, because they
require a larger, cross-functional team along with correspondingly more complex interteam communication and logistics.
 SOA is not well defined, and the vision for the final result is often not clear at the
project's inception.
 SOA can have a very positive impact on an organization, but, on the other hand, SOA
development and replacement of legacy systems can be very expensive.
 SOA project has a higher risk of failure than other projects.
To overcome these problems one of the research priorities in the field of SOA is finding a proper
design and development methodology that consider all SOA principles and causes effective and
efficient application development of this architecture. Lots of investigations has been carried out
to find out which of nowadays popularly used software developing methodologies, such as agile
methodologies or RUP,SOUP, suits SOA principles the best, or whether there is a need of a new
SOA development methodology.

3. What is Service Oriented Unified Process (SOUP)
SOUP is a software methodology that takes the best elements from RUP and XP. It is targeted
specifically at SOA projects that are underway in any organization.
The major driving factors of a typical software development project are the application
development process, project management, and the technologies used. These are all driven by the
specific consultants assigned to the project. A generic software development project has four
variables: time, budget, scope, and quality. Compromising on any one variable has an impact on
the overall project. Because of changing business needs, scope and quality are the two most
difficult factors to manage. Technological complexities can lead to problems with time and
budget management, as well.
SOA projects are significantly more complex than typical software projects because they require
a larger, cross-functional team along with correspondingly more complex inter-team
communication and logistics.
A SOA can realize great benefits for an organization, but can be costly and time consuming. If
the project is not well defined, with a clear vision for the final result from inception, there's a high
risk of failure.
The key factors that can help a SOA rollout succeed are:
 A clearly defined development process
 Enhanced lines of communication across project teams that know the business
 Clear support and governance policies
On the beginning of the SOA project there's a need for some formal software methodology
analogous to RUP that addresses all risks of the project. An agile methodology like XP might not
be formal enough and the most important drawback of it is the lack of documentation and any
up-front design of the system or of its requirements. However, after SOA project is successfully
started, continuing to use this formal methodology for SOA support can make the process too
complex.
SOUP is a six-phase methodology for SOA application development. SOUP phases represent a
distinct set of activities and artifacts that are critical to the success of a SOA project.
Figure 1 SOUP Process model
We can break the use of the SOUP process into two categories.


SOUP for initial SOA deployment
SOUP for ongoing SOA management

4. Service-Oriented Systems Development Life Cycle
A strategic approach to SOA adoption requires an iterative approach to systems development and
evolution that reflects the strong link between business strategy and development strategy. SOA
adoption is not “all or nothing.” As a matter of fact, one of the benefits of SOA adoption is that
systems and system components can be deployed gradually. What follows is a proposed
development life cycle for service-oriented systems, where each pass through the life cycle
corresponds to an iteration in Figure 2. The main differences with other iterative development
frameworks, such as the IBM Rational Unified Process (RUP), are an emphasis on activities to
establish and analyze the relationship with business goals at the beginning of the cycle, an
emphasis on evaluation at the end of the cycle, and the specification/review of business objectives
at the end of the cycle so that the requirements for each iteration follow business objectives.
Figure 2 Flow Diagram of the Expanded View of the SOA Problem Space and Solution Space

5. The SOUP Process Model
SOUP for initial SOA deployment:
An attempt to show how SOUP maps into RUP was carried out by Kunal Mittal (Mittal, 2010).
He made a comparison at a high abstraction level that showed only how SOUP phases map into
RUP Figure 3, but he did not performed any deeper analysis, i will make a deeper analysis of how
the elements of SOUP methodology maps to RUP
Figure 3 SOUP and RUP Model
Incept phase: The purpose of this phase is to understand the business needs for SOA adoption
and how SOA fits within the organization. The objective of this phase is to decide whether SOA
project is profitable by evaluating project scope and risks or not. There is a number of essential
activities that should be accomplished and a set of essential artifacts that should be created during
the incept phase. These artifacts can be mapped to activities in a following way
Activity
Artifact
Formulate the vision and the
SOA vision and scope document which outlines the overall
scope of the system
vision of the project. It also provides some boundaries that
establish the project's scope.
Define SOA strategy
SOA strategy document which is a high-level plan
determining how a project can be implemented: business
analysts analyze business requirements of clients, their
interactions with suppliers in order to determine the
advantages of service-oriented solutions and propose
appropriate strategy.
Accomplish ROI analysis
Return on Investment (ROI) document outlines costs and
savings of the project. It should determine short-term and
long-term benefits.
Create communications plan
Communications plan explains how the team of SOA
should collaborate with client’s project members and users.
Since business stakeholders know organization’s business
better than architecture team and business analysts, they can
improve processes through participation in service-oriented
analysis process.
Table 1.
Activity
Artifact

6. Formulate the vision and the
scope of the system
Define SOA strategy
Accomplish ROI analysis
Create communications plan
SOA vision and scope document which outlines the overall
vision of the project. It also provides some boundaries that
establish the project's scope.
SOA strategy document which is a high-level plan
determining how a project can be implemented: business
analysts analyze business requirements of clients, their
interactions with suppliers in order to determine the
advantages of service-oriented solutions and propose
appropriate strategy.
Return on Investment (ROI) document outlines costs and
savings of the project. It should determine short-term and
long-term benefits.
Communications plan explains how the team of SOA
should collaborate with client’s project members and users.
Since business stakeholders know organization’s business
better than architecture team and business analysts, they can
improve processes through participation in service-oriented
analysis process.
Table 1 Incept Phase of SOUP: Activity to Artifact Mapping
Define phase: The purpose of this the most critical phase for SOA project is to define the
requirements and develop use cases. The objectives of this phase are:
1. To fully understand business processes affected,
2. To collect, define and analyze functional and non-functional requirements by using a
formal requirements-gathering and management process like RUP,
3. To design support and governance model which explains how organization will support
SOA,
4. To prepare a realistic project plan,
5. To define technical infrastructure that is required to support entire SOA.
6. Creating a project plan with timelines and estimates
There is a number of essential activities that should be accomplished and a set of essential
artifacts that should be created during the define phase. These artifacts can be mapped to
activities in a following way (Table 2).
Activity
Requirements gathering and
analysis
Nonfunctional requirements
definition and analysis
Artifact
Functional requirement document: Detailed explanation of
all business requirements that SOA will group and cover as
business services.
Non-functional requirement document. This document
describes the requirements including performance
considerations, service-level agreements (SLAs),
infrastructure requirements, and etc.

7. Use case definition and
realization
Overall architecture definition
and documentation
Use case and use case realization. This document include
detailed use cases for all services that will be built.
SOA architecture document. This document describes the
overall architecture including hardware and software
components.
SOA applicability document
This document explains what projects fall within the scope
of the SOA project and how ongoing projects can be built
on top of the SOA.
Infrastructure definition document. This document includes
detailed infrastructure deployment diagrams, outlining the
servers, and the connections between them necessary to
implement the SOA.
Technical infrastructure
definition
Creating a project plan with
timelines and estimates
Project plan. This detailed plan for the whole project
includes activities, workers, milestones artifacts and
dependencies between them.
Governance and support model. This is a document which
describes how the SOA will be supported and governed also
it includes considerations such as SLA monitoring and
management.
Table 2 Define phase of SOUP: Activity to Artifact Mapping
The key deliverables of this phase are:








Functional requirements document
Nonfunctional requirements document
Use cases and use case realizations
SOA architecture document
SOA applicability document
Infrastructure definition document
Project plan
Support and governance model
The most important deliverable in this stage is the support and governance model. How will the
organization support the SOA? What are the governance guidelines? If you roll out a SOA but no
one uses it, the project is a failure. The support and governance model document can prevent that
from happening.
The business should start a project with a realistic set of plans and objectives. Extra requirements
should be left for later. An effective business-to-IT (B2IT) collaboration on requirements that can
be achieved within the expected time and budget can help ensure success.
Design phase: The purpose of design phase is to translate use case realizations and SOA
architecture document into detailed design documents. The objectives of this phase are: 1) to
create detailed design document and data base model that explain the structure of the services and
how they will be built and what database tables and relations will be created, 2) to structure

8. development process by defining the technology, coding standards and etc. There is a number of
essential activities that should be accomplished and a set of essential artifacts that should be
created during the design phase. These artifacts can be mapped to activities in a following way
(Table 3).
Activity
Create detailed architecture description with
database model
To structure the development process
Prepare for testing
Artifact
Detailed design document which explains
how services are designed and built
Database model. This document includes
ERD (Entity Relationship Diagram) of
databases used for SOA.
Application programming model which
includes guidelines on how the development
will be structured. It covers such topics as
process and technologies being used, coding
standards, deployment procedures and so on.
Testing and QA plan. This document includes
detailed test and quality assurance cases.
Table 3 Design Phase of SOUP: Activity to Artifact mapping
Construct phase: The purpose of this phase is to construct SOA project. The objectives of this
phase are: 1) to iteratively develop, integrate and test SOA, 2) to create user documentation.
There is a number of essential activities that should be accomplished and a set of essential
artifacts that should be created during the construct phase. These artifacts can be mapped to
activities in a following way (Table 4).
Activity
Iterative development
Iterative QA and testing
User documentation
Artifact
Code bases include code files that should be
stored in repositories
Test results. The results of testing and quality
assurance should be stored and kept available
for examination.
User documentation which was developed in
design phase should be kept up-to-date
including detailed documentation of code.
Table 4 Construct Phase of SOUP: Activity to Artifact Mapping
The key deliverables of this phase are:

Code base: The code should be stored in some kind of source control repository.

Test results: The results from the execution of the test cases and QA plans should be
available for examination.

Documentation: Documentation should include detailed documentation on the code and
any updates to the design documents.

10. Deploy phase: In this phase, you actually deploy your SOA. You roll it out to individual project
teams, who start using the SOA on their projects in a production setting. Perhaps the most
obvious key deliverable for this phase is your application in production. However, even more
important is the plan that establishes the projects that will pilot the SOA. This leads into the next
step of the SOUP methodology, which determines how ongoing projects will use the new
architecture.
There is a number of essential activities that should be accomplished and a set of essential
artifacts that should be created during the deploy phase. These artifacts can be mapped to
activities in a following way (Table 5).
Activity
Create deployment model
Create application model
Create support model
Artifact
Deployment model. This document describes
the structure of SOA deployment.
Application model. This document shows
guides for how to use SOA. It becomes
important as various project teams begin to
use the new architecture.
Support Model. This document organizes
systematically updates of governance and
supports model that was developed in the
Define phase.
Table 5 Deploy phase of SOUP: Activity to Artifact Mapping
The other key deliverables of this phase are:



Deployment model
Usage model
Ongoing support levels model
Support phase: The purpose of this phase is to ensure ongoing SOA support. The objectives of
this phase are to support SOA by making bug fixes, trainings and new functionality development.
There are a number of essential activities that should be accomplished but SOUP does not
provide a set of essential artifacts that should be created during the support phase. The list of
essential activities is as follows: Maintenance, Bug fixes, Training, Continuous project buy-in.

11. SOUP for ongoing SOA projects:
The SOUP methodology can still be useful for projects that are using an SOA that has already
been rolled out. In such situations, SOUP draws more heavily on XP for inspiration. Figure 4
Overlaid SOUP and XP processes shows the SOUP and XP processes overlaid on each other.
Figure 4 Overlaid SOUP and XP processes
What is the key premise here? The value of the SOA project is that it provides a well-defined
architecture and firm technology guidelines. You have a framework on which to build your
applications as services. The project teams' main tasks are building and consuming services. They
are most fit to perform these tasks because they have the necessary business domain knowledge.
However, they do not need to worry about the technical architecture or invention of technology,
as that is left to the SOA teams.
Projects of this type follow the same SOUP guidelines outlined in the last section; however, as
you'll see, each phase is significantly reduced. Many of the deliverables I describe in this section
are the same as those described previously; when necessary, I explain how they differ from their
counterparts in a project where an SOA is built from scratch.
Incept phase:
When you've got an SOA up and running, there's still development work to be done. You'll no
doubt want to build projects that consume existing services or expose new ones. In the Incept
phase of such a project, you establish the project's overall scope and vision. The key deliverables
of this phase are:

Project vision and scope: This would encompass the scope of an individual project, not
the larger SOA initiative.

Project strategy: This document describes the strategy and process for this specific
project and explains how it leverages the SOA.

ROI analysis: A detailed cost-benefit analysis for the project is crucial to help make
decisions about implementation.

12. Define phase:
In this phase, you build the tie-ins to the SOA project and understand how to leverage the SOA.
You need to identify the services that the SOA already makes available and those that still need to
be built to meet the goals of your project.
This phase of a project's lifecycle involves such activities as:




Requirements gathering
Services identification
Establishing a project plan with timelines and estimates
Test case development
The key deliverables of this phase are:






Functional requirements document: This is a typical requirements document for a
software project.
Use cases and use case realizations: These cover the new business processes being built.
SOA applicability document: This outlines how the existing SOA framework applies to
this project.
Project plan: This detailed plan for the whole project includes milestones and
dependencies.
Services strategy: This document identifies services that already exist and can be
consumed along with new services that can be exposed.
Test plan: This plan includes test cases for the new project.
The requirements gathering in this phase does not need to follow the formal standards that were
followed during SOA rollout. Instead, you can make use of agile requirements gathering
involving user stories or Class, Responsibilities, Collaborator (CRC) cards (see Resources for
more on these). In line with XP thinking, test cases are built early on in this type of project.
Design this phase:
Is really quick, because most of the design was completed in the initial SOA rollout. In this phase,
you only have to worry about how to use the services, what more needs to be built on top of the
existing services, and what new services need to be built.
The key deliverables of this phase are:

Detailed design document. This document explains how your design leverages the overall
SOA and establishes a design and application programming model.

Database model. This document encapsulates a logical and physical database design for
this specific project.

13. Construct phase:
This phase involves more assembly than new development. As more services become available,
each project will have more to reuse and less to build. XP's iterative development techniques are
ideal at this stage of development. In XP, iterative cycles are theoretically set at two weeks,
which should be more than ample time for one development-QA cycle when building a small
service or consuming a set of services in an SOA environment. With this iterative approach, an
SOA can provide valuable business agility via quick software releases.
This phase of a project lifecycle involves such activities as:



Iterative development
Iterative QA and testing
User documentation
The key deliverables of this phase are:

New services: Any new services that are being exposed will be ready by the end of this
phase.

Test results: Results from the execution of the test cases should be available to all
interested parties.

Documentation: This phase of development should produce detailed code
documentation along with any necessary updates to other documents created previously.
Deploy phase:
In this phase, you either launch an application that consumes several services, or you launch new
services. The infrastructure is managed by the SOA team; thus, this process is relatively
straightforward.
Support In this phase, you are only providing support for your new services. In doing so, you will
follow the support guidelines laid down during the original SOA project; thus, individual projects
don't need to spend much time developing new support guidelines.
Managing the SOA lifecycle
I introduced SOUP, a new software methodology for building your SOA and then realizing the
benefits of the architecture on individual projects. I’ve taken a very high-level look at how this
methodology would work, transitioning from an RUP-like methodology (for initially building an
SOA) to an XP-style agile process (for ongoing services rollout). By combining the best qualities
of these two processes, you can rely on a unified development scheme that nevertheless provides
the flexibility needed to manage different stages of an SOA's lifecycle.

14. eXtreme Programming (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 project.
Rational Unified Process (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 upfront 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.

15. Outpatient Department Management in AL-Shifa Hospital Case Study
The purpose of this section is to apply the knowledge acquired from the previous sections in this
report and use it to develop a sample application, a system that will be used as part of a patient
management system in healthcare systems in the AL-Shifa hospital.
Outpatient department is nowadays present in almost every hospital, it is a very good initiative by
hospitals as it is also very beneficial to patient also, OPD allow patients to take treatment by good
doctors without being admitting in hospital.
OPD optimizes the resources and is an outstanding service for effective health care as patient get
treated well without paying any hospital charges for bed and other services, doctor get full
support from hospital administration and inner department, they can send patient to surgeon if
necessary which are available inside hospital. Patient also need not to stay hospital for days or
weeks, they can go to home after the doctor consultation and get proper care at their homes as per
doctor advices.
For OPD we developed an desktop application for doctors sitting at OPD for knowing the number
of patients waiting outside for their turn, so that doctors can arrange their schedule accordingly
and if there are many patients waiting outside for treatment they can ask for some more doctor to
come to OPD for handling patients from hospital administration, so that every patient can be
consulted without overloading a single doctor and patient also do not have to waste time by
sitting in queue and waiting for their turn. This software helps patient saving their time by doctor
getting the list of patient waiting and by doctor taking appropriate action.
This project was developed by developing team consisting of 15 people including project leader,
tester and developers. Technology being used was PHP. Software process model used was SOUP.
SOUP is a software engineering process used to develop software.
Benefits of This Project
Benefits to doctor: This project really proved a boon for doctor, they can now well manage their
patients within the time limit decided by them, as by knowing the number of patients waiting for
their turn. Doctor can decide his schedule accordingly and by knowing the name of patient doctor
can manage its time by knowing how much time the patient needs if the patient is a old patient
i.e. the patient that comes for regular checkup and if that patient need to refer to a surgeon or to
any other department for any test than doctor can send the patient to other department without
wasting much of patient’s time in waiting. Doctors get opportunity to tackle different cases which
increases their experience and helps in diversifying their practice.
Benefits to patients: It was also beneficial for patient as if the queue is long they can ask doctor
assistant will their number will come today or not and by seeing the name of patients waiting
doctor can give an estimation that after how much time their number will come. This would
definitely save patient time. It also saves patient money by providing good infrastructure and
services at low cost, saves hospital bed charges and other hospital charges. It also saves patient
from visiting to knapsack doctor and ensures patients to be treated from authenticate doctors.

16. Benefits to hospital: This project is also very beneficial for hospital as their resources (beds and
man power) are optimized. Outpatient Department in any hospital is considered to be shop
window of the hospital. Now a day, the patients are looking for hassle free and quick services in
this fast growing world. This is only possible with optimum utility of the resources through
multitasking in a single window system in the OPD for better services. Hospital can earn well
using OPD as patient feel easy to go and get treated at OPD at low cost and by good doctors
without being admitted to hospital.
The application is accessed from both a 3270 terminal interface and a Web-based interface using
a commercially available Internet browser as illustrated in (Figure 5). SOAP and Web services are
used to expose the CICS-controlled information (Outpatient department functions) as serviceoriented architecture (SOA) service providers, which in turn are accessed using SOA service
requestors from a browser. Because the focus of this chapter is on the iterative development
process applied to specific functions of the Outpatient department application, much of the details
concerning the CICS TS configuration and Web services are omitted. You can find additional
information about these topics in Application Development for CICS Web Services, SG24-712600.
Figure 5 Patient Management System Architecture overview

17. Department Manager iterative development process
Applying the iterative process to our case study, the Patients Managing Development schedule is
divided into eight iterations with each iteration spanning three weeks. Typically spans two to
three weeks with the total number of iterations dispersed among the four SOUP phases:
Inception, Elaboration, Construction, and Transition. The iteration cycle is the heartbeat of the
project and after it has been selected, it remains constant for the duration of the project. Both the
iteration cycle and the number of iterations are project dependent with the latter directly relating
to the complexity of the project. The Patients Managing iterative development plan has one
iteration in the Inception Phase, three iterations in the Elaboration Phase, two iterations in the
Construction Phase, and two iterations in the Transition Phase. We assess and mitigate the risks
during each iteration with each iteration culminating in a minor milestone for the project and
facilitating successful achievement of the phase’s objectives. Table 6 illustrates the patients
managing project plan broken down into iterations and phases. It depicts the relationship between
the iterations and their respective phase, the relationship of the phases to each other, and the
major milestone that marks the conclusion of each phase.
Table 6 Patient Management Project Plan

18. Patients Management SOUP phases
The activities in each phase primarily focus on addressing a specific set of risks with the aim of
reducing the risks and ensuring that the project is moving forward. The milestones at the end of
each phase serve a dual process:

The milestone serves to act as a driving force to attain a specific target by providing
development status to our stakeholders, whose decisions are key to moving to the next
phase.

The milestones are checkpoints for the project as a whole, because they allow developers
and management to track the progress of the work as they complete key points in the
project lifecycle.
Table 7 further describes these phases in more detail as well as the associated major milestone
that concludes the phase.
Phase
Description
Milestone
Inception Phase
The Inception Phase will
develop
the
patients
requirements and establish the
business case for the system.
The major use cases
will be identified and a high
level Software Development
Plan will be developed. At the
end of the Inception Phase, we
will decide whether to fund
and proceed with the project
based upon the business case.
The Lifecycle Objectives
Milestone at the end of the
Inception Phase and marks the
Go/No Go decision for the
project.
Elaboration Phase
The Elaboration Phase will
refine the requirements and
develop a stable architecture.
At the completion of the
Elaboration Phase, all high
risk use cases will have been
analyzed and designed. An
executable system called an
architectural prototype will
test the feasibility and
performance
of
the
architecture.
The Lifecycle Architectural
Milestone marks the end of
the Elaboration Phase. The
major
architectural
components are in place and
stable.
Construction Phase
During the Construction
Phase, the remaining use cases
will be
analyzed and designed. The
Beta release will be developed
The Initial Operational
Capability Milestone
(completion of the beta) marks
the end of the Construction
Phase.

19. Transition Phase
and distributed for evaluation.
The implementation and test
activities to support the R1.0
and R2.0 releases will be
completed.
The Transition Phase will
prepare the R1.0 and R2.0
releases for distribution. It
provides the required support
to
ensure
a
smooth
installation.
The
Product
Release
Milestone (completion of the
R2.0 release) marks the end of
the Transition Phase. At this
point, all capabilities defined
in
the Vision document are
installed and available for the
users.
Table 7 Phases and milestones
Patients Management Inception Phase
The Inception Phase addresses business risks so that we focus on mitigating the risk that the
project might be either economically undesirable or technically infeasible. During this phase, it is
crucial that we discuss with stakeholders their needs and the problems that our solution is
attempting to solve. We scrutinize all aspects of the project as well as identify the major use
cases.
Identifying the major use cases for a this system, such as the Patient Management,
entails getting everyone’s agreement that a client ”patients” needs to be able to the information
and ability the doctor to extraction report and change login both are appear after true login.
Figure 6 Use Case for a Doctor

20. Figure 7 Patient use case
Concluding the Inception Phase
The Inception Phase for the Patient Management concludes with the Lifecycle Objective
Milestone, which indicates whether to proceed or abandon the project. At this stage, we propose a
single solution that:
 Solves the right problem
 Is technically feasible
 Is economically viable
All stakeholders agree on these points prior to taking the project to the next step that is,
developing the architecture approach in the Elaboration Phase. If all stakeholders do not agree on
these points, a decision to cancel the project is made. This can in fact be a desirable outcome of
the Inception Phase, because terminating a project at this stage is the least expensive option of all
the phases.
Patient Management Elaboration Phase
The Elaboration Phase addresses architectural and technical risks. It spans three iterations
culminating in a Lifecycle Architectural Milestone, which is an executable architecture. This is a
partial implementation of the system to verify that we have a stable architecture to support the
significant Functionality, Usability, Reliability, Performance, and Scalability (FURPS)
requirements.
During this phase, we outline the basic and alternate flows of each use case as well as identify the
most critical (important) use cases. For each critical use case, we identify the architecturally
significant (most important) scenarios for the Patient Management and use them to create the
executable architecture; that is, we design, implement, and test these scenarios. We also
document these architectural scenarios in our Software Architecture Document.

21. For each of these scenarios:

We create a use-case realization, which is a sequence or interaction diagram identifying
the components to fulfill the behavior specified by the scenario.

We develop test cases that validate the scenarios so that we know what the desired
behavior is. Test cases during the Elaboration Phase focus more on identifying problem
areas, such as load testing and performance, rather than validating that the desired
behavior is correct.
Concluding the Elaboration Phase
The Elaboration Phase for the Patient Management concludes with the Lifecycle Architectural
Milestone. Our aim at this point is to:



Bring architectural and technical risks under control.
Establish and demonstrate a sound architectural foundation.
Establish a credible plan for developing the product.

22. Patient Management Construction Phase
The Construction Phase addresses logistical risks, that is, completing the remaining work in the
allotted time. It spans two iterations culminating in an Initial Operational Capability Milestone,
which is assessing that the product is suitable to be delivered to the users.
During this phase, we do most of the work and implement all functionality. The remaining
scenarios are detailed, designed, implemented, and tested, following a pattern not unlike that of
the Elaboration Phase.
Up until this point, our testing has been focused on proving the suitability (Inception) and
technical feasibility (Elaboration) of the solution. We switch gears now to concentrate more on
testing the user interface of the solution, but we also need to ensure that prior architectural tests
continue to work as the new functionality is implemented. Because the number of test cases has
now grown, we make use of an automation tool to alleviate the manual testing effort.
Because we already have an existing COBOL application for the Replenish function, we employ
the Bottom-up-approach.
Concluding the Construction Phase
The Construction Phase for the Patient Management concludes with the Initial Operational
Capability Milestone. Our aim at this point is to:



Ensure that the solution is developed according to the requirements.
Ensure that the solution is ready to be delivered to the users and stakeholders.
Achieve adequate quality as rapidly as possible.

23. We are now ready to deploy the solution as a beta release to be evaluated by users and
stakeholders. This takes us to the Transition Phase. The following sections outline the Patients
Management Construction Phase iteration details, work product deliverables, and the use of
different tools to develop the project.
Patient Management Transition Phase
The Transition Phase addresses solution rollout (delivery) risks and brings these risks under
control. It spans two iterations culminating in a Product Release Milestone, which marks the
product completion. During this phase, we are mostly concerned about deployment and fixing
defects identified in the released product. We decide to deliver the Patient Management as two
releases: R1 containing only the 3270 components and R2 containing the Web services
components. See the following Table 8.
Table 8 Transition Phase iterations
Concluding the Transition Phase
The Transition Phase for the Patient Management concludes with the Product Release Milestone.
Our aim at this point is to:
 Deliver the solution to its users.
 Achieve user self-sufficiency.
Successful deployment of the product indicates that the Product Release Milestone has been
achieved. Of course, Product Release milestone assessment is based on the satisfaction of our
users and stakeholders.

24. Conclusion
As SOA is a new software development paradigm and the methodology for successful SOA
implementation is still not developed, lots of researches are being carried out in this area. The aim
of this paper was to compare a popularly used RUP methodology, which has provided a large
database of knowledge and best practices from successful developments, and is targeted at objectoriented paradigm solutions to SOUP - a new software development methodology for serviceoriented paradigm. Our research showed that RUP methodology cannot be used to develop SOA
applications without any adaptation to service-oriented paradigm. Also, our research showed that
SOUP methodology is still only in its first steps and should be revised, tested and improved to
assure successful SOA developments. The mapping of SOUP activities to RUP activities, SOUP
artifacts to RUP artifacts showed that: 1) there are activities and artifacts that are SOA specific
and are out of scope of RUP and this is the main reason why RUP cannot be applied in SOA
development without any adaptation, and 2) Some RUP activities like risk management that are
essential for successful SOA applications development are not included in SOUP and makes this
methodology immature and in need of reconsideration and improvement.
References

KRUCHTEN, Philippe. The Rational Unified Process An Introduction, Second Edition, Addison
Wesley (2000). ISBN: 0-201-70710-1

Sneed, Harry. “Migrating to Web Services: A Research Framework.” Proceedings of the
International Workshop on SOA Maintenance Evolution (SOAM 2007), 11th European
Conference on Software Maintenance and Reengineering (CSMR 2007), Amsterdam, the
Netherlands, March 20-23, 2007.

T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Upper
Saddle River: Prentice Hall PTR, 2005.

T. Erl, SOA Principles of Service Design. Prentice Hall PTR, 2008.

LEWIS, Grace; SMITH, Dennis, SMITH; KONTOGIANNIS, Kostas. A Research Agenda for
Service-Oriented Architecture (SOA): Maintenance and Evolution of Service-Oriented Systems,
SEI (2010). Prieiga per internet ą: <http://www.sei.cmu.edu/reports/10tn003.pdf >

Masoumeh, Department of IT, Iran Telecommunication, Research Center, Tehran, Iran
(2010). Proposed Combined Framework of SOA and RUP. Prieiga per internet ą:
<http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5534806 >

Service-oriented architecture: A brief introduction (2004) [interaktyvus]. [Žiūrėta 2011 m. kovo
31 d.] Prieiga per internet ą: <http://soaprpc.wordpress.com/2009/05/06/service-orientedarchitecture-a-brief-introduction/>

H. M Shirazi, N. Fareghzadeh, and A. Seyyedi, A combinational approach to service identification
in SOA, Journal of Applied Sciences Research 5(10) (2009), 1390-1397.

25. Appendixes
Use Case Model for Project: (Management Dental Clinic)
-
This is (doctor)Main use case diagram consist of manage patient and extraction report.
The system do verify to information that are inputted.
extraction report and change login both are appear after true login.
(Doctor)Main Use case Diagram

26. -
This is (doctor) management patient consist of (add patient –delete patient –update patient – view all
patient) .
The Manage Patient Appear if only if the Information login is true
only the doctor or secretary can controlling it.
Manage Patient Use case Diagram

27. -
This is (doctor) extraction report consist of search patient and print report .
Only the doctor or the secretary can controlling it.
The Manage Patient Appear if only if the Information login is true.
(Doctor)Extraction Report Use case diagram
-
This (doctor) change login use case is dependency on current password.
The system verify information and change login if the inputting is true But if the
current password is false the system cannot change password.
(doctor)change login use case

28. -
This is (Secretary)Main use case diagram consist of manage patient and extraction report.
The system do verify to information that are inputted.
extraction report and change login both are appear after true login.
(secretary) Main Use case
-
This is (secretary) extraction report consist of search patient and print report .
Only the doctor or the secretary can controlling it.
- The Manage Patient Appear if only if the Information login is true
(Secretary) Extraction Use case

29. -
This (secretary) change login use case is dependency on current password.
The system verify information and change login if the inputting is true But if the current password is
false the system cannot change password.
(Secretary)Change Login use case
Sequence Model for Project:(Management Dental Clinic)

30. ID
1
Name
Add New Patient
Description
This Function to add new Patient information after input
login information
And verify if the patient exist in database.
Actors
Doctor or Secretary or both.
Pre-Conditions

Inputs
Must input patient information (name , age ,gender,……).
Must be Login.
Flow of Events
Basic Path
Alternative Paths
1. After actor login app verify login and then control
panel appears.
2. Select manage patient
3. Enter add new patient
Alternative flow of events 1:
By Update information you can clear all Info and input new
Info.
Post-Conditions

The system display new form success input
[Outputs]
Message indicating the success of the operation.
Related
Screenshots
Message indicating the success of the operation.

31. Add new Patient Sequence

32. ID
2
Name
Search patient sequence
Description
This sequence to search about patient
And then to show his information.
Actors
Doctor or Secretary or both.
PreConditions

Inputs
Patient ID
Must be Login.
Flow of Events
Basic Path
1.After actor login app verify login and then control panel
appears
2. The user selects search patient and app show search screen
3. The user should enter patient ID and app bring it from
storage location
PostConditions

Things that are true after the use case ends
[Outputs]
The actor get patient information
elated
Screenshots
Display success mission.

33. search patient sequence diagram

34. ID
3
Name
Update patient sequence
Description
This sequence to update patient information
Actors
Doctor or Secretary or both.
PreConditions


Inputs
Patient ID – other way to search.
Must be Login.
The actor who can do this
Flow of Events
Basic Path
1.After actor login app verify login and then control panel
appears
2. The user selects update patient and app show update screen
3. The actor should update patient info and app replaces old
info new
PostConditions

Things that are true after the use case ends
[Outputs]
Message indicating the success of the operation
related
Screenshots
Display message to success mission.

35. Update sequence diagram

36. ID
4
Name
view patients sequence
Description
This sequence to view all patients
Actors
Doctor or Secretary or both.
PreConditions


Inputs
No inputs
Must be Login.
The actor who can do this
Flow of Events
Basic Path
1.After actor login app verify login and then control panel
appears
2. The actor selects view patients and app show update screen
PostConditions
[Outputs]

Things that are true after the use case ends
App shows all patients

37. View All patient sequence diagram

38. ID
3
Name
Change Password patient sequence
Description
This sequence to update patient information
Actors
Doctor or Secretary or both.
PreConditions


Inputs
Patient ID .
Must be Login.
The actor who can do this
Flow of Events
Basic Path
1.After actor login app verify login and then control panel
appears
2.The user extract report and app extracts reports
3. The user selects update patient and app show update screen
4. The actor should update patient info and app replaces old
info new
PostConditions

Things that are true after the use case ends
[Outputs]
Message indicating the success of the operation
related
Screenshots
Display message to success mission.

39. Change Password Sequence diagram

40. ID
3
Name
Delete Patient sequence
Description
This sequence to update patient information
Actors
Doctor or Secretary or both.
PreConditions


Inputs
Patient ID .
Must be Login.
The actor who can do this
Flow of Events
Basic Path
1.After actor login app verify login and then control panel
appears
2. The user selects update patient and app show update screen
3. The actor should update patient info and app replaces old
info new
PostConditions

Things that are true after the use case ends
[Outputs]
Message indicating the success of the operation
related
Screenshots
Display message to success mission.

41. Delete Sequence diagram

42. Activity Model for Project:(Management Dental Clinic)
Login Activity Diagram

43. Add new Patient Activity Diagram

44. Search Patient Activity Diagram

45. Class Diagram for Project:(Management Dental Clinic)
java class for Project