Submitted by Luiza Maria Pereira de Oliveira (luiza.oliveira@ufpe.br) on 2015-05-15T14:50:47Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) DISSERTAÇÃO Orlando Silva de Oliveira.pdf: 4687464 bytes, checksum: d739eb25e47ccd00cea540bac40b2285 (MD5) / Made available in DSpace on 2015-05-15T14:50:47Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) DISSERTAÇÃO Orlando Silva de Oliveira.pdf: 4687464 bytes, checksum: d739eb25e47ccd00cea540bac40b2285 (MD5) Previous issue date: 2014-11-12 / A Arquitetura Orientada a Serviços (SOA) oferece um modelo arquitetônico que visa aprimorar a eficiência, a agilidade e a produtividade de empresas. Nesse modelo, os serviços são os principais meios para que os objetivos estratégicos sejam atingidos. Entretanto, o desenvolvimento de sistemas que utilizam este estilo de arquitetura tem exigido novas estratégias dentro da Engenharia de Software (ES), principalmente no tocante à disciplina de Engenharia de Requisitos (ER). Por outro lado, observa-se que as abordagens da Engenharia de Requisitos Orientada a Objetivos (GORE) têm ganhado notoriedade nos últimos anos. De fato, as abordagens orientadas a objetivos apresentam mecanismos que não são ofertados pela ER tradicional, como por exemplos capturar os objetivos dos stakeholders e as características do sistema em um mesmo modelo. Assim, é possível usar esse modelo para analisar e identificar se o sistema proposto atende aos objetivos dos stakeholders. Esse é um importante tipo de análise no contexto organizacional. No entanto, a literatura não apresenta uma forma sistemática para identificar serviços em modelos de requisitos orientados a objetivos. Além disso, há uma lacuna a ser preenchida na transição dos requisitos (espaço do problema) para a arquitetura equivalente (espaço da solução), no contexto da SOA. Dessa forma, este trabalho apresenta uma abordagem sistemática para a identificação de serviços em modelos GORE descritos em i* e a posterior obtenção da arquitetura SOA descrita em SoaML. A abordagem foi validada através de um estudo empírico com usuários reais.

Made available in DSpace on 2014-06-12T15:58:03Z (GMT). No. of bitstreams: 2 arquivo3244_1.pdf: 2061206 bytes, checksum: d9bbab1debda0a2122b877cceb8484ed (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Conselho Nacional de Desenvolvimento Científico e Tecnológico / O reuso de software é um fator extremamente importante para empresas interessadas em aumentar sua produtividade, diminuir os custos e o tempo durante o desenvolvimento de sistemas e melhorar a qualidade de seus produtos e serviços. Nesse contexto, Linhas de Produto de Software (LPS) e Arquitetura Orientada a Serviços (SOA) são duas estratégias que estão atualmente recebendo uma grande atenção, tanto na área acadêmica quanto na indústria de software. Os conceitos de linhas de produto e arquitetura orientada a serviços compartilham alguns objetivos e características que podem ser usados em conjunto para aumentar as taxas de reuso de software. No entanto, para o resultado dessa junção ser otimizado, é necessário utilizar um processo de desenvolvimento bem definido. Caso contrário, a equipe de desenvolvimento poderá produzir software de maneira não sistemática, aumentando as chances de falha, o tempo e o custo de desenvolvimento. Com essa visão, esse trabalho apresenta uma abordagem para o projeto de arquiteturas para linhas de produto orientada a serviços, constituída de um conjunto de atividades e sub atividades com entradas e saídas especificadas, sendo cada uma delas realizada por um conjunto predefinido de papéis com responsabilidades definidas. Essa abordagem visa ajudar arquitetos de software a projetar arquitetura orientada a serviços para domínios específicos. Para garantir a qualidade da abordagem desenvolvida, uma pesquisa extensiva foi realizada para analisar o atual estado da arte de processos para o desenvolvimento orientado a serviços. Foram então considerados os pontos fracos e fortes dos processos estudados com o intuito de identificar e preencher as lacunas neles existentes. Por fim, essa abordagem foi validada e refinada por meio de um estudo acadêmico experimental preliminar

Made available in DSpace on 2014-06-12T16:01:20Z (GMT). No. of bitstreams: 2 arquivo8451_1.pdf: 2875255 bytes, checksum: 742b167ac5ca2801d819d5cc5058cfc4 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / A constante necessidade em reduzir o time-to-market tem obrigado as empresas a buscar novas alternativas para o desenvolvimento de software que possibilitem atender às demandas impostas pelo mercado. A Computação Orientada a Serviços (COS) é um paradigma que tem ganhado espaço nesse contexto, pois o conceito de serviço presente nessa abordagem suporta o desenvolvimento rápido, de baixo custo e baseado em reuso. Um dos desafios atuais da COS é encontrar uma metodologia que possa dar suporte ao desenvolvimento de aplicações seguindo este paradigma. Algumas metodologias têm sido propostas nos últimos anos, porém nenhuma delas define seus processos com base na atividade de composição de serviços, que é fundamental para o reuso. Diante desse contexto, este trabalho apresenta uma metodologia para desenvolvimento de software orientado a serviços com foco na atividade de composição de serviços. Para demonstrar a aplicabilidade da metodologia, um exemplo é apresentado e seus resultados discutidos

To support the difficult process of SOA adoption, SOA maturity models are published. In this thesis a literature analysis introduces the area of SOA maturity models and highlights benefits and criticism. As a result, the combined SOA maturity model (CSOAMM), a model to facilitate the interpretation and comparison of SOA maturity models, is proposed. CSOAMM is a model with 10 levels that describes SOA maturity by combining level characteristics of two recently published maturity models: SIMM and SOAMM. CSOAMM was created by a comparative analysis in combination with a relational content analysis. The model can be used for collaboration between companies and points out that a common understanding of SOA adoption exists.

This thesis describes the development of a SOA-based architecture for integrating large EDI-using manufacturing companies purchasing processes with smaller non-EDI capable manufacturing companies, using online services. The underlying need for this project lies with the fact that these small manufacturing companies risk to miss out on business, due to their inability to communicate via the industry standard EDI format. At the same time, getting EDI-capable involves significant investments in software licenses, connectivity services and consulting or training that these small companies may not be ready to make. The mentor company of this thesis project, System Andersson, produces resource planning software for this type of companies and would like to be able to provide them with an easy to use way of “jacking in” EDI support into their businesses, without having to make such significant investments. Ideally this feature would be developed as a standalone subscription based service that could be provided to users in such a way that their existing System Andersson software could connect to it and no further hard- or software would be needed on site. This EDI-enabling should be as easy as to be entirely transparent for the end-user companies. The task handed to the author was thus to develop an architecture for how such a subscription based service could be developed. Furthermore, in order to promote re-use and simplify development, the architecture was to be based on SOA concepts. As a result of the project, such an architecture has been developed. The architecture details two services for translating and storing for later delivery a number of EDI message types of the EDIFACT variety. The architecture also specifies communications protocols (SOAP over HTTPS and AS2 over HTTPS) and APIs (web services) for how to communicate with these services. These specifications can be used to implement a system that performs the necessary integration, so that the smaller companies may indeed communicate via EDI. The fitness of the developed architecture has been tested by implementing a prototype version of such a system based on it. It has also been validated by way of comparing to how well it adheres to SOA design principles. All in all, this design appears to be quite sound and presents a working solution to the studied problem.

Through the entry of web 2.0 the technologies behind web development has changed dramatically. Asynchronous JavaScript and XML (AJAX) is the umbrella term for different techniques that make it possible to build rich and interactive user interfaces in today’s web browsers. Service Oriented Architecture (SOA) describes how common services can be bundled and published so they can be consumed by different systems. The company SYSteam Evolution AB, which has requested this project, wanted a web application that shows a graphical activity chart in order to easier view ongoing projects. The goal for this project is to develop a demo platform that shows how AJAX and SOA can be used to create flexible and reusable applications. To reach the goals, many different frameworks and technologies need to cooperate and work together. This report will describe the different technologies that have been used and explain the different steps in the development job. The result of the work has lead to a demo platform that uses many different technologies to show a graphical activity chart. The job requestor and the author are very pleased with the result of the work. / Genom intåget av web 2.0 har teknologierna bakom webbutveckling ändrats drastiskt. Asynchronous JavaScript and XML (AJAX) är samlingsnamnet på ett antal tekniker som gör det möjligt att bygga rika och interaktiva applikationer i dagens webbläsare. Tjänsteorienterad arkitektur, ”Service Oriented Architecture” (SOA) talar om hur gemensamma tjänster paketeras och publiceras så att de kan konsumeras av olika system. Uppdragsgivaren till detta examensarbete är företaget SYSteam Evolution AB. Företaget vill ha en webbapplikation som visar en grafisk aktivitetskarta för att enklare kunna överblicka pågående projekt. Målet med arbetet är att ta fram en demoplattform som visar hur AJAX och SOA kan användas för att skapa flexibla och återanvändbara applikationer. För att lyckas med uppdraget måste olika ramverk och teknologier kombineras och fungera tillsammans. Denna rapport kommer att förklara de olika teknikerna som använts, samt även förklara de olika stegen i utvecklingsarbetet. Resultatet av arbetet har utfallit i en demoplattform som använder många olika teknologier för att visa grafisk aktivitetskarta. Uppdragsgivare och uppdragstagare är mycket nöjda med resultatet av arbetet.

No description available.

This thesis emphasizes on investigating the relationship between the quality attributes and service oriented architecture (SOA). Due to quality attributes requirements drive the design of software architecture, it is necessary to maintain the positive quality of SOA and improve the negative quality of SOA. This thesis gives an introduction to SOA, Enterprise Service Bus (ESB) and MULE. Then, it covers information on quality of systems and tactics for achieving each quality attribute. Finally, we discuss the quality of SOA in detail, and illustrate how to set up a SOA and how to improve its quality using a case of an order for supermarket. / Order of supermarket

Extensive efforts are being conducted in the area of integrating and merging together applications and systems in public administration, including healthcare. One approach against integrating applications is to introduce a Service Oriented Architecture (SOA). This could be conducted by modifying the previously stand-alone systems and make them act as services or components, communicating through some sort of common services or directly interoperate. This thesis describes several standards and best practices addressing integration currently present in healthcare. Additionally, a number of business key aspects connected to Service Oriented Architectures are described and also how customers and contractors could benefit from these. By conducting an industrial case study of an integration project, standards and business aspects could be applied and used to analyze the project. Both software engineering issues and business aspects are identified, important to the study.

Legacy-system sköter idag flera kritiska affärsprocesser hos många företag och banker. Dessa system är dyra att underhålla och uppdatera med nya funktioner. Legacy-systemenär också svåra att anpassa till en tjänsteorienterad arkitektur eller SOA (Service OrientedArchitechture). Därför vill företagen börja fasa ut dessa system. SOA är ett tankesätt i hur man strukturerar ett system. Allt ska vara uppbyggt av tjänster som inte är beroende avvarandra och därför i framtiden blir lättare att byta ut, ändra eller ta bort. Eftersom ingen tjänst ska vara beroende av någon annan skadas ingen annan del av systemet om en tjänst ändras. Eftersom fler och fler företag idag vill övergå till en SOA så letar de efter sätt att migrerasina legacy-system till modernare plattformar. Det finns flera olika sätt att migrerera legacy-system. Alla har olika fördelar och nackdelar. En av de säkrare metoderna är Chicken Little (steg-för-stegmetod), men den tar längre tid än att till exempel använda sig av metoden Cold Turkey som även kallas Big Bang. Big Bang för att man byter ut hela systemet på till exempel en helg eller liknande (drastisk metod). Flera företag har också specialiserat sig på att automatiskt översätta gammal kod till modernare, den tekniken heter transcoding. Det finns även företag som jobbar med att få bland annat Cobol att jobba ihop med modernare utvecklingsplattformar såsom Java. Ett av de mer aktiva företagen som arbetar med detta är Micro Focus, som har utvecklat ett bibliotek som gör att du kan starta Cobol-program från Java eller .NET. Författarna har med hjälp av deras Java-bibliotek skapat ett program åt Bluegarden som kan starta upp Cobol-program. Programmet skapades för att påvisa vad de kan använda för att slippa flera steg i uppstart av Cobol-program. För att undvika att man får legacy-system i framtiden har det även kommit fram flera underhållsmodeller. Underhållsmodellerna fungerar på olika sätt, men alla har som mål att undvika legacy-system. / Legacy systems today manages many critical business processes of many organisations and banks. These systems are expensive to maintain and update with new features. Legacy systems is also difficult to adapt to a SOA (Service Oriented Architecture). Therefore, the companies want to begin phasing out these systems. SOA is an approach in how to structure a system. Everything should be built of services that are not depending on each other and therefore in the future will be easy to replace, update or delete. Since no services will be dependent on any other, you can change one without harming another. More and more companies today want to move to a SOA, therefore they are looking for ways to migrate their legacy systems to modern platforms. There are several ways to migrate legacy systems. Every way has different advantages and disadvantages. One of the safer methods is called Chicken Little, but it takes longer than, for example using the method Cold Turkey. Several companies have also specialized in automatically translating old code to a modern programming language, this technique is called transcoding. There are companies that are working to get Cobol to work with more modern languages such as Java. One of the bigger companies that is developing ways to combine COBOL and Java is Micro Focus. They have developed a library that allows you to start COBOL programs from Java. To avoid legacy systems in the future, several maintenance models have been created. Maintenance models are structured in different ways, but all have the goal to avoid future legacy systems.