Significant time is spent by practitioners to analyze use-cases written in Natural Language (NL). With only prescriptive templates to describe complex scenarios, common errors like misinterpretation and oversight can have costly consequence later during system development. A semi-automatic approach based on NL processing can reduce the time spent on requirement analysis and bootstrap design activity. However, linguistic community has adopted pipeline processing to handle NL ambiguities where several sequential tasks aid in solving a bigger task. Choosing NL processing techniques depends on the domain and task to accomplish. As use-cases are domain specific it is crucial to identify suitable pipelines to process them. This is highlighted in our evaluation of two pipelines consisting of syntactic and semantic techniques on use-cases found in theory and practice. We believe, the promising results has opened up the need for exploring more task specific NLP pipelines and evaluation thereof.

Large, multinational software development organizations face a number of issues in supporting software design and modeling by geographically distributed architects. To address these issues, we present CoDesign, an extensible, collaborative, event-based software modeling framework developed in a distributed, collaborative setting by our two organizations. CoDesign's core capabilities include real-time model synchronization between geographically distributed architects, as well as detection and resolution of a range of modeling conflicts via several off-the-shelf conflict detection engines.

In this work we present a case study of a SOA realization exercise at a business information provider firm, which deals with disparate sources of data in-order to provide reliable reports to its clients. Unlike typical enterprise scenarios, where applications are required to be service enabled, the key requirement here was to service enable its data acquisition, quality check, reporting and other processes which are either mostly manual or ETL based workflows. This paper also addresses how shared services, business processes, rules, and semantics are used to provide quality and agility to the internal processes many of which are entirely dependent on the type of data received. The case and the scenario are chosen specifically to emphasize the fact, that mere web-services implementation does not lead to service oriented architecture, but it is the appropriate usage of them.

Summary form only given. Service oriented architecture (SAO) is latest trend in trying to bridge the gap between business strategists and IT architects. Architecting services from an enterprise perspective does not just involve identifying and fitting pieces together, but managing and addressing cross cutting concerns or non functional requirements (NFRs). With most of the discussion on SOA being around abstracting the business functions as reuse-able services, IT architects have to additionally worry about the existing system qualities. So, a flat view over services has to be complimented with an approach of looking into these additional obligations, which adds a new dimension of complexity during the adoption of SOA. This tutorial is intended to provide our insights into managing this complexity throughout the different phases of SOA adoption, by minimizing the risk through calculated assumptions. We will initially set the context of the different phases of service adoption. We will then present an approach for managing the complexities of NFRs through earlier defined adoption phases. We will conclude with a discussion of the essential artifacts and tools for guiding service design.