Software architecture for the Cuban ERP inventory module

Summary

In the present work, a proposal of Service Oriented Architecture for the Inventory Module of the Cuban ERP is exposed, so that it enables it to be: portable, secure, scalable and integrable with other systems and at the same time it is extensible to others. ERP modules.

erp-service-oriented-architecture

To achieve the proposed objective of defining and describing the software architecture, a study was made of the elements that constitute it and the current trends according to the most prestigious authors on the subject, as well as the experience of developing the Inventory Management System and Warehouses (SIGIA).

The success of the definition and description of the architecture will depend mainly on the architectural decisions that are made during its development, the most appropriate technology that is decided and aspects of the design that allow a favorable development of the system itself, where they are taken into account. the relationships and configurations between the components and that allows organizing the structure of the system that is developed, giving the entire team a clear idea of what is being developed.

Keywords

Software architecture, style, pattern, component, framework, Service Oriented Architecture (SOA), web service, integration, Enterprise Resource Planning (ERP), XML, SOAP, UDDI, WSDL.

Introduction

With the disappearance of socialism in the Union of Soviet Socialist Republics and the intensification of the US blockade against Cuba in the 1990s, the Cuban economy was paralyzed. Due to this, the country was in need of a process of redesigning economic policy. Since then, a gradual program of economic measures began to be carried out with the objective of overcoming the situation of the nation at the lowest possible social cost.

As a result of the economic difficulties the country was facing, the Cuban state began to invest in various strategic sectors of the economy and began to allocate large amounts of resources to raise the level of computerization in society, where the best example Reliable and current is the creation of the University of Computer Sciences to produce high-quality software and insert it in the world market. As a result of this strategy, more efficient and higher quality business systems have been obtained, meeting the technological demands of the moment.

Starting with business improvement, companies work to achieve greater efficiency in their production or in the services they provide. Hence the use of computer systems that allow the automation of business processes and thus make them much more efficient. One of the systems that makes this possible are the Enterprise Recourses Planning (ERP), which are information management systems that integrate and automate in a single application all the business processes of a company, understood by this: production, sales, purchases, logistics, accounting, project management, inventories, warehouse control, orders, payroll, human resources, among others.

ERPs provide support to business users, efficient information management for decision-making, fast response times and a decrease in the total costs of operations. (Martínez, et al., 2001).

One of the most important processes in the planning of resources of a company is the inventory systems and therefore it constitutes a solid base in the development of ERP systems.

In today's economy, inventory management has reached the pinnacle of business management problems because it is a critical component of productivity. If inventories are kept too high, the cost could lead to a company having financial liquidity problems. On the other hand, if an insufficient inventory level is maintained, customers may not be served satisfactorily, which would result in reduced profits and market loss (Sanchez, 2006). So it can be seen that carrying healthy inventories will guarantee any company and industry greater reliability when moving products within the warehouse.

In Cuba there are Inventory Management Systems, among them are: The Inventory System of Cultural and Natural Heritage (SIP), as its name implies, was created for heritage purposes such as: registration, control and conservation of the same. The Computerized System for the Processing of the Forest Inventory (INVENFOR 1.0), carried out in order to record and process the data obtained from the forest inventory in order to estimate the dasometric parameters of the stands in a way that contributes to more forest management planning efficient. Other examples of systems are: DRIM, FONDUS, SI and IHMM 2000 from the company GET (Group of Electronics for Tourism), the latter with the aim of being used in hotel facilities.

They all have something in common, and that is that most of these systems are specialized for the operation of certain companies, hence they are not flexible, but rather, closed in their design, difficult to standardize the inventory management process and the integration with other systems, essential elements that are proposed to be solved.

This is the reason why it is necessary to develop a new inventory management system that meets the current needs of companies and the country as such, equipped with the latest technology, so that it is more flexible, modern, friendly, reliable and safe, and also that it is able to integrate with other systems. Precisely of this that it is configurable from the particular needs of the clients, that it complies with the new regulations established by the Ministry of Finance and Prices. In short, that it meets all the new requirements that the old systems do not provide because they have become obsolete.

For the satisfactory development of any software system and that at the same time guarantees a certain quality and low costs, it is necessary to use development methodologies, which guide this process. A significant element in the development process is the conception of a high-level design, which allows to organize and understand the structure of the system being developed and gives the whole team a clear idea of what is being developed.

It is a fact that during the software development process situations arise that limit and hinder the process itself. Among them you can see: the scarce reuse, the poor selection of software elements, architectural styles, architecture patterns, communication protocols, composition of design elements, assignment of functionality to design elements, tools, frameworks, synchronization problems and access to data, programmers writing code in any way as long as it meets what they want the program to do, influencing all this on issues of scalability, performance and cost. Where the solution to all these problems is in the correct definition and description of a Software Architecture.

The Software Architecture arises from the need to make the systems more modular, allowing the reuse of components, so its implementation considerably reduces the cost. It also allows maintaining a low coupling between the elements of the system, but with very high cohesion, since the structure of the components, their ways of communicating and the relationships that exist between them are clearly established.

All the above led to the definition of the following problem:

How to make high-level design decisions in the development process of the Inventory Management System that allows it to be scalable, secure, portable and integrable with other business management systems?

The research focuses on the object of study: Development Process of the Inventory Management System. For this, the following general objective is proposed : Propose a Service-Oriented Software Architecture that allows the Inventory Management System to be scalable, secure, portable and integrable with other business management systems.

Defining as field of action: Software Architecture for the Inventory Management System.

The research was carried out using the following tasks to fulfill the proposed objective :

Carrying out a study of the state of the art of Software Architecture to learn about the different architectural approaches, how they evolved, main trends and definitions, as well as the most significant architectural styles that are booming in the development of business systems. Architectural styles to use, justify the use of these, as well as their application. Definition of the frameworks and development tools to be used. Definition and description of the Architecture. Validation by specialist criteria.

The following methods were used to carry out the tasks:

Theoretical Methods

Historical - Logical: To determine current trends in the development of architectural models and approaches. Analytical - Synthetic: To reach conclusions in the investigation from the information that is processed and to specify characteristics of the proposed architectural model. Systemic Method: To define the elements of the system and their relationships.

Empirical methods

Measurement: for the evaluation of response times in critical situations of the case study.

Possible outcomes

Proposal for a Service Oriented Software Architecture for the Inventory Management System that allows it to be scalable, secure, portable and integrable with other business management systems.

The present work is structured in three chapters

Chapter 1: Theoretical Foundation

In this chapter the theoretical foundation of the research is carried out based on a study of the state of the art of Software Architecture, as well as the different architectural approaches, main trends and definitions. A study is made of the most significant architectural styles that are booming, exposing their advantages and disadvantages. In short, all those aspects that will allow modeling the theoretical framework that underpins the research.

Episode 2:

In this chapter the proposal of solution to the problem posed in the theoretical design of the research is made, it is given by the Artifact Document Description of Architecture proposed by the University of Informatics Sciences to be used in productive projects.

Chapter 3:

This chapter specifies the tools that will support the architectural proposal made in the previous chapter for the Inventory Management System. In addition, an analysis of the proposed solution is made from the point of view of quality.

Chapter 1: theoretical foundation

Introduction

In this chapter the theoretical foundation of the research is carried out, a study of the art of Software Architecture, as well as of the different architectural approaches, main trends and definitions. A study of the most significant architectural styles that are booming in the development of business and management systems, exposing their advantages and disadvantages to select the right one for the development of the Inventory Management System. An analysis of the different levels of abstraction of Software Architecture, architectural modeling languages, the Service Oriented Architecture style as a challenge of the present, and quality in Software Architecture.

State of the art of Software Architecture

Software Architecture is a young practice of just a few years of constant work. It has its origins in the 60s, but it was not until the 90s that Dewayne Perry and Alexander Wolf, expose it in the sense that is known today.

Similarly, Bass defines it as follows: “The Software Architecture of a computer or program system is the structure of the system's structures, which comprises the components of the software, the properties of those externally visible components, and the relationships among them." (Pressman, 2002).

On the other hand, the definition that is most internationally recognized by many architects is taxed by the industry and belongs to IEEE 1471, which cites thus: «Software Architecture is the fundamental organization of a system embodied in its components, the relationships between them and the environment and the principles that guide its design and evolution. » (Reynoso, 2006).

Despite the abundant number of definitions that exist of Software Architecture, the vast majority agree that this refers to the broad structure of the system (high level of abstraction), a structure consisting of components and relationships between them. For what Software Architecture is defined as the structure and organization of the software elements of a Computer System, how and under what conditions and configurations these elements are going to communicate.

It can be concluded that Software Architecture is: a discipline independent of any development methodology, represents a high level of system abstraction and responds to non-functional requirements, since these are satisfied by modeling and designing the application. In the same way, it can be concluded that Software Architecture is not: software design, a mature regulation, treated in the same way in academia as in industry.

1.2.1.2. Style

In general, when one talks about architecture, in one way or another, it refers to something specific that is closely related: classifications. The fact is that it is not only as a classificatory issue, but that each architectural form has a great relationship and is associated with tools, concepts, experiences and problems.

These classifications have been called in various ways, such as: architecture classes, architectural types, recurring archetypes, species, topological paradigms, common frameworks, and several dozen others. For more than a decade these architectural qualifications have been called: styles, or alternatively architectural patterns. Styles are only manifested in descriptive theoretical architecture with a high level of abstraction; patterns everywhere. (Reynoso, et al., 2004)

The first explicit definitions of style seem to have been proposed by Dewayne Perry and Alexander Wolf in October 1992. They establish reasoning about architectural styles as one of the fundamental aspects of the discipline. “A style is a descriptive concept that defines a form of articulation or architectural organization. The set of styles catalogs the possible basic forms of software structures, while the complex forms are articulated through composition of the fundamental styles ”(Perry, et al., 1992).

According to Pressman (Pressman, 2002), a style describes a category of system that encompasses a set of components that perform a function required by the system, a set of connectors that enable communication, coordination and cooperation between the components, the restrictions that they define how the components are integrated to form the system, and the semantic models that facilitate the designer's understanding of all parts of the system. The architectural style is also a construction pattern.

Styles combine components, connectors, configurations and constraints. The description of a style can be formulated in natural language or diagrams, but it is best to do it in an Architectural Description Language (ADL) or in Formal Specification Languages (LFE).

It can be concluded that:

One style contemplates the four “Cs” of the AS (elements, connectors, configurations, and constraints). It serves to synthesize solution structures that will later be refined through design. Few abstract styles encapsulate a huge variety of concrete configurations. They define the possible patterns of the applications, avoiding architectural errors. They allow evaluating alternative architectures with known advantages and disadvantages before different sets of non-functional requirements.

1.2.1.3. Pattern

The framework concept is used in many areas of software system development. You can find frameworks for the development of web applications, desktop applications, medical applications, for game development, and for any field that one can think of.

In general, the term framework refers to a software structure made up of customizable and interchangeable components for the development of an application. In other words, a framework can be considered as an incomplete and configurable generic application to which the latest pieces can be added to develop a specific application.

So in summary, a framework is the skeleton of an application that must be adapted by the programmer according to their specific needs to develop an application.

1.2.2. Trends

Although today there is nothing that explicitly endorses the existence of Software Architecture schools, nor a reference that analyzes the particularities of each one, at present, six currents can be broadly distinguished. Belonging to one of these currents does not represent something deterministic, since at different times some practitioners of Software Architecture perform different jobs operating in different frameworks, or because they simply change their conception.

The proposed division of Software Architecture schools is as follows:

Architecture as a stage of engineering and object-oriented design. Obviously it would be Grady Booch's; For him, Software Architecture is "the logical and physical structure of a system, forged by all the strategic and tactical decisions that are applied during development." Other definitions reveal that Software Architecture, in this perspective, concerns decisions about organization, selection of structural elements, behavior, composition and architectural style that can be described through the five classic views of the Kruchten 4 + 1 model. (Reynoso, 2006) Structural architecture, based on a static model of styles, ADLs and views. The representatives of this trend are all academics, mostly from Carnegie University. It is also the vision of the dominant Software Architecture in the academy, and although it is the one that has made the most important effort to recognize Software Architecture as discipline, its categories and tools are still poorly understood in industrial practice. Inside the movement you can see different divisions. There is an informal variant of "boxology" and a more formalist side, represented by Mark Moriconi's group at the SRI in Menlo Park. In principle, three modalities can be recognized in terms of formalization; the more informal ones use verbal descriptions or box diagrams,those of intermediate character use ADLs and the most demanding use formal specification languages such as CHAM and Z. Throughout the current, architectural design is not only the highest level of abstraction, but also does not have to coincide with explicit configuration of applications; references to programming languages or pieces of code will rarely be found, and in general no one talks about classes or objects. While some participants exclude the data model from the concerns of the Software Architecture (Shaw, Garlan, etc.), others insist on its relevance (Medvidovic, Taylor). (Reynoso, 2006)references to programming languages or pieces of code will rarely be found, and in general no one talks about classes or objects. While some participants exclude the data model from the concerns of the Software Architecture (Shaw, Garlan, etc.), others insist on its relevance (Medvidovic, Taylor). (Reynoso, 2006)references to programming languages or pieces of code will rarely be found, and in general no one talks about classes or objects. While some participants exclude the data model from the concerns of the Software Architecture (Shaw, Garlan, etc.), others insist on its relevance (Medvidovic, Taylor). (Reynoso, 2006)Radical architectural structuralism. It is a detachment from the previous trend, mostly European, which assumes a more confrontational attitude with the UML world. Within this movement there are at least two trends, one that flatly excludes the relevance of object-oriented modeling for Software Architecture and another that seeks to define new meta-models and stereotypes of UML as corrective to the situation. (Reynoso, 2006) Architecture based on patterns. While acknowledging the importance of a model emanating from object-oriented design, it is not as tightly tied to UML in modeling as it is to CMM in methodology. The text on patterns that this variant recognizes as reference is the POSA series by Buschmann and others, and secondarily the text of the Band of Four. Design consists of identifying and articulating pre-existing patterns, which are defined in a similar way to architectural styles. (Reynoso, 2006) Process architecture. Since the beginning of the 21st century, centered in the SEI and with the participation of some of the first generation Carnegie Mellon architects and many new names of the second: Rick Kazman, Len Bass, Paul Clements, among others. It attempts to establish life cycle models and requirements elicitation techniques, brainstorming, design, analysis, alternative selection, validation, comparison, quality estimation and economic justification specific to Software Architecture. (Reynoso, 2006) Architecture based on scenarios. It is the newest stream. It is a predominantly European movement, centered in the Netherlands. It recovers the nexus of Software Architecture with the requirements and functionality of the system, occasionally blurred in classical structural architecture. UML use case diagrams are often used in this stream as an informal or occasional tool, since use cases are one of the possible scenarios. Use cases are not object oriented. The authors associated with this modality have been, apart from the encoders of ATAM, CBAM, QASAR and other SEI methods, the Dutch architects of the Technical University of Eindhoven, Brije University, the University of Groningen and Philips Research. (Reynoso, 2006)

1.2.3. Difference between Software Architecture and Design

The academic community of Software Architecture differs substantially from confusing design with architecture, although some practitioners when referring to the subject leave the relationship between both fields very ambiguous.

To some extent, architecture and design serve the same purpose. However, Software Architecture focuses on system structure and component interconnections, distinguishing itself from traditional software design, such as object-oriented design, which focuses more on modeling lower-level abstractions., such as algorithms and data types. As high-level architecture is refined, its connectors may lose prominence, spreading across lower-level architectural elements, resulting in the transformation of architecture into design. (Reynoso, et al., 2004).

Software Architecture is a relatively new discipline in software design and actually encompasses design methodologies as well as analysis methodologies. The contemporary software architect performs a combination of roles as systems analyst, system designer, and software engineer. But architecture is more than a relocation of functions. The concept of architecture attempts to subsume analysis and design activities into a broader and more consistent design framework. But architecture is somewhat more integrated than the sum of analysis on the one hand and design on the other. The integration of methodologies and models is what distinguishes the AS from the simple juxtaposition of analysis and design techniques. (Albin, 2003).

Architecture concerns a higher level of abstraction; deals with components and not procedures; of the interactions between these components and not of the interfaces; of the restrictions to exert on the components and the interactions and not of the algorithms, the procedures and the types. As for the composition, that of architecture is coarse-grained, that of design is of fine procedural composition; Interactions between components in architecture have to do with a high-level protocol (in the non-technical sense of the word), while those in design concern procedural-type interactions (messages, routine calls) (Perry, 1997).

So it can be concluded that Software Architecture is not software design, since it occurs at an earlier stage in the development of a project at a high level of abstraction, dealing with components, connectors, configurations, restrictions, leaving the design to detail Lower-level, more refined architectural elements such as: procedures, algorithms, and data types.

Levels of Abstraction of Software Architecture

1.3.1. Architectural Styles

1.3.1.1. Style Classification

How many and what are the styles?

In a study carried out by Mary Shaw and David Garlan (Garlan, et al., 1994), they propose the following taxonomy, in which what were previously called “architectures” are intermingled with “design models”:

Pipe-filters Data abstraction and object-orientation organization Implicit, event-based invocation Layered systems Repositories Table-oriented interpreters Distributed processes. A particular form of distributed process is, for example, the client-server architecture. Main program / subroutine organizations. Domain-specific software architectures. State transition systems. Control process systems. Heterogeneous styles.

In Software Architecture in Practice, a fundamental text by Bass, Clements and Kazman (Bass, et al., 1998), a systematization of style classes in five groups is provided:

Data flow (data movement, without receiver control of what comes "upstream")
- Sequential Batch Process Data Flow Network Pipe-Filters
Call and return (computation-dominated style, usually with a single control thread)
- Main Program / Subroutines Abstract Data Types Objects Client-Server Call Based Layered Systems
Independent components (dominated by communication patterns between independent processes, almost always concurrent)
- Event-oriented systems Communication processes
Data-centric (dominated by complex central storage, manipulated by independent computations)
- Repository Blackboard
Virtual machine (characterized by the translation of an instruction into some other)
- Interpreter

The styles, unlike patterns, are a few, and they are grouped into style classes, the most current, concise classification assumed during the investigation being the following (Reynoso, 2005):

Data Flow Styles
- Pipe and filters
Data Centered Styles
- Slate or Repository Architectures
Call and Return Styles
- Model-View-Controller (MVC) Layered ArchitecturesObject-Oriented ArchitecturesComponent-Based Architectures
Mobile Code Styles
- Virtual Machine Architecture
Heterogeneous styles
- Process control systems Attribute Based Architectures
Peer-to-Peer Styles
- Event-Based ArchitecturesService-Oriented Architectures (SOA) Resource-Based Architectures

1.3.1.2. Most Popular Styles

In the 1960s and 1970s it was natural to structure an application in terms of the functional services it was to provide. In fact, methodologies such as analysis and structured design started from a hierarchical functional decomposition that was later transformed into procedures within the application. With the increasing complexity of applications and the need to evolve them, this approach was not enough. In the 80s and 90s object-oriented software development became popular, seeking, among other objectives, to allow the construction of more maintainable applications. (Casallas, et al., 2005)

Today, objects do not seem to be enough, not because they are no longer good, but because the problem has changed. These changes are a consequence of technological advances and the increase in customer expectations. For example, non-functional features have become more critical and the problem of application integration has become a priority. It is necessary to have flexible architectures and as independent as possible of the tools used. In (Annex 1) it is shown how the architectures of the systems have evolved over the years.

Object Oriented Architecture

This type of architecture is known in several ways, including: Object-Based Architectures, Data Abstraction and Object-Oriented Organization.

The components of this style are the objects, or rather instances of the abstract data types. In the classic characterization of David Garlan and Mary Shaw, objects represent a class of components that they call managers, because they are responsible for preserving the integrity of their own representation. An important feature of this aspect is that the internal representation of an object is not accessible from other objects. (Garlan, et al., 1994)

According to Billy Reinoso (Reynoso, et al., 2004), if the characteristics of object-oriented architectures were to be summarized, it could be said that:

The components of the style are based on OO principles: encapsulation, inheritance and polymorphism. They are also the units of modeling, design, and implementation, and objects and their interactions are at the center of concerns in the design of the architecture and structure of the application. The interfaces are separate from the implementations. In general, the distribution of objects is transparent, and in the state of the art of technology it hardly matters if the objects are local or remote. The best example of object orientation for distributed systems is the Common Object Request Broker Architecture (CORBA), in which interfaces are defined using Interface Description Language (IDL); An Object Request Broker mediates interactions between client objects and server objects in distributed environments.it can be admitted or not that an interface can be implemented by multiple classes. There are many variants of the style; some systems, for example, allow objects to be concurrent tasks; others allow objects to have multiple interfaces.

Advantage:

You can modify the implementation of an object without affecting its clients. An object is a reusable entity in the development environment

Disadvantages:

In order to interact with another object through a procedural invocation, its identity must be known.It presents cascading side effect issues: if A uses B and C uses it too, the effect of C on B can affect A. Granularity very fine for large systems. Layered Architecture

Garlan and Shaw define layered style as a hierarchical organization such that each layer provides services to the immediately superior layer and uses the benefits provided by the immediately inferior layer (Reynoso, et al., 2004). (See annex 2)

In a layered style, connectors are defined by protocols that determine the forms of the interaction. Topological style constraints can include a more or less rigorous limitation, which requires each layer to operate only with adjacent layers, and the elements of a layer to be understood only with other elements of the same; if this demand is relaxed, the style is supposed to stop being pure and lose some of its heuristic capacity (MSDN, 2004); Naturally, the possibility of replacing a layer without affecting the rest is also naturally lost, reducing the flexibility of the assembly and complicating its maintenance.

It is sometimes argued that excessive crossing of many levels involves eventual performance degradations; But many times more, the purity of the layered architecture is sacrificed precisely to improve it: placing, for example, business rules in the stored procedures of the databases, or articulating query instructions in the layer of the user interface.

Advantage

Modularity (to some extent) Supports design based on increasing levels of abstraction, which in turn allows implementers to partition a complex problem into a sequence of incremental steps. Provides extensive reuse. Easily supports system evolution; changes only affect neighboring layers Implementations can be changed while respecting interfaces with adjacent layers.

Disadvantages

It is difficult to reason a priori about the required layering. Formats, protocols, and transports of communication between layers are often specific and proprietary. Not all systems can be layered. Component-based architecture

Currently in software development there is a great need to make use of the reuse of parts or modules of existing software, which could be used to generate new extensions of applications or complete applications. When talking about reuse in engineering processes, the concept of "component" is very implicit, since efficient parts of software that can be used to build applications are known as "software components".

There are several definitions of this term (Software Component):

According to Krutchen, a component is a non-trivial, almost independent and replaceable part of a system that fulfills a function within the context of a well-defined architecture. A component complies with a set of interfaces and provides the physical realization of them. (Brown, et al., 1998). The Software Engineering Institute (SEI) at Carnegie Mellon University formulated a definition with the purpose of consolidating the different opinions about what a software component should be: “a component is an implementation opaque in functionality, subject to third-party composition and compliant with a component model ”(Bachmann, et al., 2000). According to Szyperski, a software component is a composition unit with contractually specified interfaces and only explicit context dependencies.A software component can be independently deployed and is subject to composition by third parties. (Szyperski, 2002).

It can be seen that most of the definitions revolve around the essential of a component, which is an implementation of a software artifact, which executes one or several functionalities, released by services, seen as a set of interfaces and provides the physical realization of they.

Characteristics:

One of the most important characteristics of the components is that they are reusable. For this, the components must satisfy at least the following set of characteristics:

Identifiable: a component must have a clear and consistent identification that facilitates its cataloging and search in component repositories. Accessible only through its interface: the component must expose to the public only its characteristic set of operations (interface) and hide its implementation details. This feature allows one component to be replaced by another that implements the same interface. Services are invariant: the operations offered by a component, through its interface, must not vary. The implementation of these services can be modified, but they should not affect the interface. Documented- A component must have adequate documentation to facilitate its search in component repositories, evaluation, adaptation to new environments, integration with other components, and access to support information.

The dominant evaluation of the component style highlights its greater versatility with respect to the object model, but also its lower adaptability compared to the service-oriented style (Reynoso, et al., 2004).

Advantage:

Software reuse. It leads to a higher level of software reuse. Simplify the tests. It allows tests to be run by testing each of the components before testing the complete set of assembled components. Simplify system maintenance. When there is a weak coupling between components, the developer is free to update and / or add components as necessary, without affecting other parts of the system. Higher quality. Since a component can be built and then continually improved by an expert or organization, the quality of a component-based application will improve over time.

Disadvantages:

If the components do not exist, they have to be developed and a lot of time can be wasted, as well as the fact that these components may have conflicts if a new version comes out of these, it is possible that these components will have to be re-implemented. are in the hands of the system developers. Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) consists of loosely coupled and highly interoperable application services. To communicate with each other, these services rely on a formal definition that is independent of the platform and the programming language (for example WSDL: Web Services Description Language). The interface definition encapsulates the particularities of an implementation, making it independent of the manufacturer, the programming language, or the development technology (such as Java or.NET).

With this architecture, it is intended that the developed software components are very reusable, since the interface is defined following a standard; thus, a service developed in CSharp could be used by a Java application.

One of the most outstanding characteristics of SOA is that it is based on contracts, where the provider establishes the rules of communication, transportation, and road and exit data that will be exchanged by both parties. To see more SOA characteristics see (Annex 3).

What is SOA?

SOA is a conceptual architecture. It organizes business functions as interoperable services. It allows reuse of services to satisfy business needs. SOA is standards-based. Manufacturer independence. SOA is an enterprise-level IT strategy.

SOA is a style of architecture in which the business processes of the system to be built are exposed as high cohesion and low coupling independent services that encapsulate these processes and can be invoked through well defined interfaces.

What is not SOA

SOA as such is not:

Project Development Methodology. Business Architecture Methodology.

SOA as an architectural style

Component: ServiceConnectors: Before, RPC - Now, message passing Configuration: Distributed Restrictions (Constraint): Low coupling, programming model independence, platform independence, transport and protocol by industry agreement

Advantage

Improve decision making.
- Unified panoramic. More information with better quality.
Improve employee productivity.
- Optimal access to systems. No limitation of ICT
Strengthen relationships with customers and suppliers.
- Greater responsiveness to customers.
More productive and flexible applications. Safer and more manageable applications.

Disadvantages

Call times are not negligible, thanks to network communication, message size, among others. This necessarily implies the use of reliable messaging. The response of the service is directly affected by external aspects such as network problems, configuration, among others. It must handle unreliable communications, unpredictable messages, retries, messages out of sequence, etc.

1.3.2. Architectural Patterns

There is a widely used categorization divided into 2 of the most widespread architecture pattern systems, being the same: that of Pattern Oriented Software Architecure (POSA) (Buschmann, et al., 1996) and that of Pattern of Enterprise Application Architecture (PEAA).) (Fowler, et al., 2002).

POSA categories

In the POSA architecture pattern reference book, patterns are divided as follows:

From Mud to Structure: These patterns help avoid an abundance of components or objects. In particular, they support a controlled decomposition of a system task into cooperating sub-tasks. Distributed Systems Interactive Systems Adaptive Systems

In (Annex 4) the distribution of POSA patterns in the categories listed is shown, and then (Annex 5) shows a brief explanation of some of them.

PEAA Categories

In PEAA (Fowler, et al., 2002), they describe a large number of patterns oriented to the architecture of business applications.

In PEAA the following categories of patterns are defined:

Layering: Patterns to divide a system into layers. Organization of domain logic: Ways of organizing domain objects. Mapping to Relational Databases: Relates to communication between domain logic and data repositories. Includes mapping between object models and relational databases. Web Presentation: Web presentation is one of the challenges that business applications have had to overcome in recent years. Web thin clients provide many advantages, one of the main ones being ease of distribution (it is not necessary to install software on client computers). This category includes a series of patterns to manage the web presentation. (Welicki, 2007)Concurrency: Management of concurrency. Today's web-based applications have high concurrency management needs. Session State: Patterns for session management on Web servers. Distribution Strategies: Distribution of objects in multiple locations, based on empirical knowledge in clients.

In (annex 6) the distribution of the patterns defined in PEAA in the categories exposed above is shown.

The terms architectural pattern and architectural style are often confused and many of the students of the discipline seem to be unclear about it. With the intention of making a clear comparison between architectural style and architectural pattern, (Annex 7) presents some of the differences between these concepts, built on the basis of the approach (Buschmann, et al., 1996).

1.3.3. Relationship Between Levels of Abstraction

In (Annex 8) the relationship of abstraction between the concepts of architectural style, architectural pattern and design pattern is shown.

Styles and patterns help the architect to define the composition and behavior of the software system, and a suitable combination of them allows to meet the quality requirements, thus allowing the software system to build to last over time.

However, the organization of the software system must be available to all those involved in the development of the system, since it establishes a communication mechanism between them. This is achieved by representing architecture in different ways, thus obtaining a description of it in such a way that it can be understood and analyzed by all involved, with a view to obtaining a quality system. These descriptions can be established through architectural views, notations such as UML, and architectural description languages (Bengtsson, 1999).

The architectural views, through different levels of abstraction, highlight various issues that concern those involved in development. So it is interesting to analyze these perspectives of an architecture, and the way in which they help all those involved in the development process to reason about the quality attributes of the system.

1.3.4. Frameworks

In section 1.2.1.4 a brief definition has been given about what a framework is, so this section will attempt to address more about them.

The main objectives of a framework are: to accelerate the development process, reuse existing code and promote good development practices such as the use of patterns, among others.

The work of the framework user must be, on the one hand, to select, instantiate, extend and reuse the components that it provides, and on the other, complete the architecture of the framework by developing specific components, which must be coupled in the framework, thus achieving develop different applications following the structural restrictions imposed by the framework.

What are the advantages of using a framework?

Those derived from using a standard; among other:

The programmer does not need to consider a global structure of the application, but the framework provides a skeleton that must be "filled in." It makes collaboration easier. Anyone who has had to fight with the source code of another programmer, or even with his own, will know how difficult it is to understand and modify it; therefore, anything that is defined and standardized will save time and work for collaborative developments. It is easier to find tools (utilities, libraries) adapted to the specific framework to facilitate development.

Although the use of frameworks is a good practice for the development of a software system, it does not mean that one must be used, whether known or not, or anything like that. This will depend on the magnitude of the project and the experience that the development team and the architect have.

According to one of the principles of secure programming, why not use an already defined framework, and take advantage of the work of other developers? In other words, why reinvent the wheel? If you have something that has been tested, that works, and is in operation, there is no need to do something that does the same, this is not very useful and can only bring complications such as waste of time.

It is true that the use of a framework implies a certain initial cost (learning curve), but this is something that is compensated in the long run during the development of a software project.

SOA: Challenge of the Present

Service Oriented Architecture is a concept of software architecture that defines the use of services as basic constructions for the development of applications. It is an application architecture where the functionalities are defined as independent services, with accessible, well-defined interfaces that can be called in given sequences to form business processes.

SOA has emerged as the best way to meet the challenge of doing more with fewer resources. It promises to make reuse and integration much easier, helping to reduce development time and increasing organizational agility. Not surprisingly, 80% of IT organizations are deploying applications using SOA with underlying web services. SOA provides greater flexibility to face changes in both the business environment and technological infrastructure ”(Reynoso, 2005).

Gartner, a leading provider of research and analysis to the global information technology (IT) industry, in 2003 states: “By 2008, SOA will be the prevailing practice of software engineering, ending 40 years of dominance by monolithic architectures. (probability 0.7) ”(Natis, 2003).

1.4.1. Reasons to use SOA

There are several reasons for a company to adopt an SOA approach, and more specifically a SOA approach based on web services:

Reuse: The fundamental factor in the change to SOA is the reuse of business services. Business functions, within a company and with business partners, can be exposed as web services and reused to meet new business needs. Interoperability: The goal of a loosely coupled architecture is for customers and services to communicate regardless of the platform on which they reside. Communication protocols with web services are independent of the platform, coding language and operating system, thus facilitating communication with business partners. Scalability: Because SOA services are loosely coupled, the applications that use those services scale easily. This is because there is very little dependency between client applications and the services they use. Flexibility: It is another feature that provides the weak coupling between services. Any change in the implementation of one of them would not affect the rest as long as the interface is maintained. Cost efficiency: SOA architectures are based on exposing existing services to be reused. By using web services to expose these services, the existing web infrastructure is reused in virtually all organizations, thus greatly limiting the cost.

1.4.2. SOA elements

This architecture presents a way of building distributed systems that provide functionality to the application as services for end-use applications or other services.

Annex 9 shows the elements that could be observed in a service-oriented architecture. In it, two areas can be distinguished, one that covers the functional aspects of the architecture and the other that covers aspects of quality of service. The elements are briefly described below (Endrei, et al., 2004):

Features
- Transport: is the mechanism used to carry service demands from a service consumer to a service provider, and responses from the provider to the consumer. Service communication protocol: it is an agreed mechanism through which a service provider and a service consumer communicate what is being requested and what is being answered. Service Description: It is an agreed schema to describe what the service is, how it should be invoked, and what data the service requires to be invoked successfully. Services: Describes a current service that is available to use. Business processes: is a collection of services, invoked in a particular sequence with a particular set of rules, to satisfy a business requirement. Service Registry: is a repository of service descriptions and data that service providers can use to publish their services, as well as service consumers to discover or find available services.
Quality of service
- Policy: is a set of conditions or rules under which a service provider makes the service available to consumers. Security: it is a set of rules that can be applied for the identification, authorization and control of access to service consumers. Transactions: is the set of attributes that could be applied to a group of services to deliver a consistent result. Administration: is the set of attributes that could be applied to manage the services provided or consumed.

SOA collaborations follow the publish, discover, and invoke paradigm, where a service consumer dynamically locates a service by querying the service registry to find one that meets a certain criteria. If the service exists, the registry provides the consumer with the contract interface and the address of the provider service. (Endrei, et al., 2004)

Annex 10 illustrates the entities (roles, operations and artifacts) in a Service Oriented Architecture where they collaborate.

Each entity shown in the diagram in (Annex 10) can take the role of consumer, supplier and / or registry:

A service consumer is an application, software module, or other service that requires a service, and executes the service according to an interface contract. A service provider is a network addressable entity that accepts and executes queries. of consumers, and publishes its services and its interface contract in the service registry so that the service consumer can discover and access the service. A service registry is in charge of making possible the discovery of services, containing a service repository available and allowing the interfaces of service providers to be viewed by interested consumers.

The operations are:

Publish. In order to access a service, its description must be published so that a consumer can discover and invoke it. Discover. A service consumer locates a service that meets a certain criteria by consulting the service registry. Bind and Summon. Once a consumer's description of a service is obtained, the consumer invokes it according to the information in the service description.

Finally, the artifacts in a service-oriented architecture are (Alvez, et al., 2006):

Service. A service that is available for use through a published interface and that can be invoked by a service consumer. Service Description. A service description specifies how a service consumer will interact with the service provider, specifying the query and response format from the service. This description can also specify the set of preconditions, post-conditions and / or quality of service levels.

Analyzing the aforementioned, it can be concluded that the basic element in this type of architecture is service, but only with this device could not design an SOA. To form an SOA, the conjunction of operations, services, messages and business processes is basically necessary.

1.4.2.1. Types of Services

Core Services: They can be data or logic focused and encapsulate features like complex calculations, data access, and complex business rules. Intermediary services: adapter services, facades, etc. They are usually stateless services. Process services: business services that encapsulate process logic. They tend to retain state and can reside in BPM tools. Public services: services accessible by third parties (outside the organization).

A business service is a reusable software component, with full functional meaning, and which is made up of (see Annex 11):

Contract: specification of the purpose, functionality, form of use and service restrictions. Interface: mechanism for exposing the service to users. Implementation: must contain logic or data access.

1.4.3. Web services

Service Oriented Architectures, in contrast to Object Oriented Architectures, consist of highly interoperable and loosely coupled application services. Where these services can be seen as the evolution in complexity of a distributed component, differing in what they are (Alvez, et al., 2006):

Much less coupled with your client applications than components. Less granularity than components. They are not necessarily designed and implemented as part of an end-to-end application. They are independently controlled and managed. Exposes their functionality through open protocols. and platform independent. Even risking performance and resource consumption, they are transparent about their location on the network, thus ensuring scalability and fault tolerance.

In general, the services include both business logic and data management, relevant to solving the problem for which they were designed. A service works as a standalone application, having its own business rules, data, administration and operation procedures, scalability, security, fault tolerance, exception handling and configuration policies. It exposes all its functionality using a message-based interface, so communication with the service is done through messages and not method calls. These messages must contain or reference all the information necessary to be understood.

Web services communicate applications, allowing information to be shared regardless of how they were created, what operating system or platform they are running on, and what devices are used to access them. Communication is characterized by the exchange of XML messages and by being independent of the communication protocol. To achieve this independence, the XML message is wrapped appropriately for each protocol thanks to the creation of the SOAP transport protocol (Simple Object Access Protocol: Simple Object Access Protocol). (Alvez, et al., 2006)

The Web Services Description Language (WSDL), expressed in XML, describes how to access the service, what functions it has, what arguments it needs and what each one returns.

The other fundamental technology involved is that of Universal Description, Discovery and Integration (UDDI: Universal Description, Discovery, and Integration). UDDI is a directory of web services where you can publish the services offered, give characteristics of the type of service, and perform searches.

In summary, SOAP defines an XML protocol for basic interoperability between services, WSDL introduces a common language to describe services, and UDDI provides the infrastructure required to programmatically publish and discover services. Together, these specifications allow applications to interact following a loosely coupled model independent of the underlying platform.

1.4.3.1. Associated Technologies

WSDL

The language of description of web services, was born in September 2000 by Microsoft, IBM and Ariba, and constitutes a standard for the description of services of the World Wide Web Consortium (W3C), organization that guides development on the web. (Endrei, et al., 2004)

In essence, WSDL is a contract between the service provider and the client whereby the service provider indicates (Alvez, et al., 2006):

What functions can be invoked What types of data are used by those functions What transport protocol will be used to send and receive messages (typically, but not only, SOAP messages) How to access services. Essentially, by what URLs the services are used.

SOAP

It is a simple protocol for the exchange of structured information in a distributed and decentralized environment. It defines how two objects in different processes can communicate through the exchange of XML data. It uses XML to define an extensible messaging framework by providing a message format that can be exchanged over a variety of underlying protocols. The framework was designed to be independent of any programming model or any specific semantics of any implementation (W3C, 2007).

The fact that SOAP uses XML has its advantages such as the ease of understanding by people, but at the same time it has its drawbacks because the messages are longer.

UDDI

It is a central element of the group of standards involved in web services technology. It is the mediator through which potential clients are known with the service providers. It defines a standard method for publishing and discovering services in the SOA context (Alvez, et al., 2006).

The UDDI specification was born almost at the same time as the WSDL specification, from the same companies. The current version is 3.0, a specification that dates from August 2003, being managed by the Organization for the Advancement of Structured Information Standards (OASIS). The implementation of these specifications is called “UDDI Registration”, which provides a set of registration and consultation web services via SOAP.

The functional purpose of a UDDI record is the representation of data and metadata about web services. Both for use on a public network and within an organization's internal infrastructure, a UDDI registry offers a standards-based mechanism for classifying, cataloging, and managing web services so that they can be discovered and consumed by other applications.

Data structures in UDDI

The information stored in a UDDI record is a set of so-called "UDDI data structures". These structures, in XML, defined in the specification, are the ones that the client will exchange with the UDDI registry. Each instance of these structures is uniquely identified with an identifier called Universal Unique Identifier (UUID) (OASIS, 2004).

The main high-level structures are as follows (Alvez, et al., 2006):

BusinessEntity. It contains basic company information: contact person, a classification of the company according to some of the defined taxonomies, as well as a description in natural language of the company's activities. PublisherAssertion. A company can declare its relationship with other companies, for example, as partners or as customers. Each of these relationships is modeled as a PublisherAssertion. BusinessService. This element shows the services offered by a company. These services may or may not be web services. A BusinessEntity is made up of one or more businessService elements, and a businessService element can be used by several BusinessService elements. BindingTemplate. This element contains references to technical descriptions (for example, URLs pointing to technical manuals) and access URLs for web services. Each BusinessService element can have one or more BindingTemplate elements. TModel. This element describes how you interact with the web service and its behavior. Among its data is the URL where the WSDL document is located. The categories in which the service can be included may also appear here (they may be different from those that could appear in BusinessEntity).

1.4.4. Composition of Services

In situations where a software system, to complete a business process, has to interact with other systems regardless of their physical distribution and heterogeneity, Service Oriented Architectures are more than useful.

From Service Oriented Architectures and more precisely from the use of web services, a new concept arises called service composition. This composition not only allows to model the business process but also maximizes the potential that SOA offers through the integration of data and applications.

The composition of services involves finding a mechanism that allows two or more of them to cooperate with each other to resolve requirements that are beyond the scope of their individual capacities. Some of the basic requirements that must be met are (Alvez, et al., 2006):

Asynchronous interactions with services: in order to give the possibility of creating processes that take place over long periods of time. Simultaneous interactions between services: this introduces parallel processing which results in a considerable increase in efficiency. Exception handling: A process based on multiple services may fail to execute if at least one of its components fails. The occurrence of errors must be taken into account and mechanisms must be provided to handle them. Transactional integrity: a long-running process may eventually fail, in this case part of the actions already taken may be required to be undone.

Two terms commonly used to refer to collaboration between services are orchestration and choreography. Both are directly related to composition but focus on complementary aspects of the interaction between services.

Orchestration

A process can be considered a service orchestration when it is fully controlled by a single entity. This process fully defines the interactions with the component services and the logic required to correctly conduct those interactions. This type of process can be understood as private and executable since only the entity that is orchestrating the process knows the flow of control and information that follows the process that is being orchestrated. In this way, a process is created that uses different services, manipulating the information that flows between them, converting, for example, the output data of some services into the input data of another. Here, each participating entity implements and controls its own process (Cubillos, et al., 2004).

Choreography

A process is a choreography of services when it defines the collaborations between any type of component applications, regardless of the language or platform in which they are defined. A choreography process is not controlled by a single participant. Unlike orchestration, choreography can be seen as a public, non-executable process. Public because it defines a common behavior that all participating entities must know, and not executable because it is intended to be seen more as a business protocol that dictates the rules so that these entities can interact with each other (Cubillos, et al., 2004).

1.4.5. SOA & Web Service

An SOA is often misunderstood and confused with web services. SOA is an approach to systems design, it directs how technological resources will be integrated and what services will be exposed. In turn, web services are an implementation methodology that uses specific standards and language protocols to execute the SOA solution.

A Service Oriented Architecture is a method of designing and building loosely coupled software solutions that expose your business functions as software services accessible through programming for use by other applications through the publication of interfaces. Web services represent an implementation of a Service Oriented Architecture but not all SOA applications can be considered web services, such is the case of Representational State Transfer (REST).

Despite this, web services are the current technology, and apparently the technology that is here to stay. In fact WSDL continues to develop, and all technologies beyond the description language that has to do with web services continue to do so in a very fast-paced way.

On the other hand, Service Oriented Architectures are a much broader concept than web services, although these are the current implementation.

A web service is SOA if (Reynoso, 2005):

The interfaces are based on web protocols (HTTP, SMTP, FTP) The messages are based on XML.

1.4.6. SOA Maturity Model

What is a Maturity Model?

It allows to measure the current state of a business architecture regarding the use of SOA. It allows to establish an evolution path.

Why a Maturity Model?

Enables layered learning including good practices Forms the foundation for communicating and extends capabilities Helps build itineraries Forms the foundation for building incremental SOA adoption

The maturity model proposed in this section consists of five levels: starter services, architectural services, business services, collaboration, business metrics, and business optimizations. These levels are going to allow scaling in profit of an SOA since in this type of architectures it goes from less to more (See annex 12). This maturity model is proposed by Progress Software Corporation, a well-known software company dedicated to providing business application platforms, including SOA and integration infrastructures. It has products in the software market recognized as: SONIC ESB, among others.

ADLs and UML

ADL

The Architecture Description Languages (ADL: Architecture Description Language) allow you to model an architecture before programming the applications that compose it, analyze its adequacy, determine its critical points and eventually simulate its behavior. They are well recognized by the academic community of Software Architecture, however they do not seem to enjoy the same acceptance in industrial practice, as they are not used in their software projects.

These supply constructs to specify architectural abstractions and mechanisms to decompose a system into components and connectors, specifying how these elements combine to form configurations and defining families of architectures or styles. (Reynoso, et al., 2004)

ADLs are characterized by the abstraction they provide to the user, in addition most of the views provided by these languages contain predominantly architectural information and the analysis provided by the language is based on architectural level information.

Some of the advantages that ADLs propose are:

It is possible to describe the behavior and its associated elements, such as the type of events they produce, or to which they respond, including descriptions or high-level documentation. Ease with which information regarding the system can be entered and maintained. they can be refined as necessary, for different types of analysis.

Despite all the aforementioned, it can be said that ADLs are convenient, but they have not yet been shown to be essential, especially due to the permanence of UML, now with version 2.0 (Reynoso, et al., 2004).

UML

The Unified Modeling Language (UML) specializes in building, specifying, visualizing, and documenting the elements that occur in the Object Oriented Software Systems software development process. It is made up of various graphic elements that combine to form diagrams and because it is a language, it has rules for combining such elements. It offers support for classes, relationships, behavior by interaction, packaging, among others. These elements can be represented by various diagrams offered by this language which are: classes, objects, use cases, sequence, collaboration, states, activities, components and development.

Despite not qualifying as an ADL at all, it has been proven that it can be used not so much as an ADL in its own right, but as a metalanguage to simulate other ADLs, and in particular C2 and Wright (Reynoso, et al., 2004).

In UML they identify:

Elements (abstractions that constitute the basic building blocks) Relationships (Link the elements) Diagrams (Graphical representation of a set of elements)

UML provides a notation for the description of the projection of the software components in the hardware, corresponding to the physical view of the Kruchten 4 + 1 model for the description of software architectures (Kruchten, 1999).

In UML there is support for some of the concepts associated with software architectures, such as components, packages, libraries and collaboration, so it can be said that the basic elements of the architecture can be modeled very well with UML. But for a total representation of the architecture, other tools and languages would be necessary, since the total representation is not only the communication that exists between its components, it is also necessary to document and justify everything done to achieve a good architectural design.

Quality in Software Architecture

The Software Architecture of the Software Systems to be built, becomes an important factor to ensure that it has a high level of quality. Having a good Software Architecture is of utmost importance, since this is the heart of all Software Systems and determines what the quality levels associated with the system will be.

From the above it can be deduced that the objectives of evaluating an architecture is to know if it can enable the requirements, quality attributes and restrictions to ensure that the system to be built meets the needs of the stakeholders and to what extent it does so. In addition to analyzing and identifying potential risks in its structure and properties, which may affect the resulting software system.

It should be noted that non-functional requirements are also called quality attributes. A quality attribute is a quality characteristic that affects an item. Where the term characteristic refers to non-functional aspects and the term element to component (Gómez, 2007).

Evaluation techniques

There are a group of techniques to evaluate that are classified into qualitative and quantitative (Brey, et al., 2005) (see annex 13):

Questioning or qualitative techniques. They use qualitative questions to ask architecture
- Open. Early Specific to the Application Domain. Specific to the System. Advanced architecture.
Measuring techniques. He suggests making quantitative measurements to architecture.
- Uses architectural metrics such as coupling, module cohesiveness, inheritance depth, modifiability, simulations, prototypes, and experiments

In general, qualitative evaluation techniques are used when the architecture is under construction, while quantitative evaluation techniques are used when the architecture has already been implemented (Gómez, 2007).

For what qualities can an Architecture be evaluated?

Broadly speaking, Bass establishes a classification of quality attributes in two categories (Camacho, et al., 2004):

Observable via execution: those attributes that are determined by the behavior of the system at runtime. The description of some of these attributes is presented in (Annex 14). Not observable via execution: those attributes that are established during the development of the system. The description of some of these attributes is presented in (Annex 15).

What results does the evaluation of an Architecture produce?

Once the evaluation has been carried out, a report must be prepared. That it must be presented as a preliminary document, in order for it to be corrected by the people who participated in the evaluation. The content of the report answers two types of questions (Gómez, 2007):

Has the most appropriate architecture been designed for the system? Which of the proposed architectures is the most appropriate for the system to be built?

In addition to answering these questions, the report also states:

The degree to which the quality attributes were met Prioritized list of the quality attributes required for the architecture being evaluated Risks and not risks

Today there are several methods for evaluating a Software Architecture that verify the compliance or not of certain quality attributes, some being more specific than others, such as: Architecture Trade-off Analysis Method (ATAM), Bosch (2000), Active Design Review (ADR), Active Reviews for Intermediate Design (ARID), Losavio (2003).

There are other architecture evaluation methods that evaluate a specific quality attribute, such as: Architecture Level Modifiability Analysis (ALMA), Performance Assessment of Software Architecture (PASA), Scenario based Architecture Level Usability Analysis (SALUTA) and Survivable Network Analysis (SNA).

Regardless of how specific or not the evaluation method may be, the vast majority have something in common: the scenario technique is used as a way of verifying to what extent the architecture responds to the quality attributes required by the system.

One evaluation method is not better than another, but rather evaluates, under certain conditions, a given quality attribute. So it is concluded that depending on the conditions and what you want to evaluate, it will be the evaluation method used (which does not have to be only one).

Relationship between Software Architecture and Quality Attributes

During the development process of any software system, architectural design decisions are made that allow achieving certain and certain quality attributes. For this, the architect must frequently question the impact that this decision will have on other quality attributes.

Each decision incorporated into a software architecture can potentially affect quality attributes (Bass, et al., 2000). So it can be said that making such decisions generally have consequences such as:

Formulation of arguments that explain how the decision made allows achieving the proposed quality attributes. Questions regarding the impact of making such a decision, on other quality attributes.

The relationship between Quality Attributes and Software Architecture has several benefits (Camacho, et al., 2004):

It greatly enhances the process of architectural analysis and design, as the architect can reuse existing analyzes and explicitly determine agreements rather than on the fly. Once the architect understands the impact of architectural components on one or more attributes of quality, it would be able to replace one set of components with another when deemed necessary. Once the relationship between architecture and quality attributes is codified, it is possible to build a test protocol that will enable third-party certification.

Partial conclusions

From the objectives proposed for this chapter, the following can be concluded:

Throughout this chapter the main aspects within the discipline have been exposed such as: conception of the main definitions, current trends, newest and most prevalent styles in the world of business applications, exposing their characteristics, advantages and disadvantages. The architectural patterns and levels of architecture abstraction that helped to understand concepts such as: architectural styles and frameworks were analyzed. Topics such as quality in Software Architecture have also been addressed, defining the main quality attributes and methods used to verify to what extent the architecture complies with the quality parameters established.Likewise, Service Oriented Architectures were analyzed as the maximum exponent of the present that allowed it to be adopted to apply it in the solution proposal since it will provide greater flexibility to the system in the face of the changing business that companies experience today and the ease of integration that provides this type of architecture.

Business partners: Person or company that is the co-owner of the company or company, in other words, is a partner of the company to which part of it belongs.

Download the original file