SaaS Series Introduction 14: SaaS Software Development Analytics

1 Introduction

The real problem, not whether the computer has the ability to think, but whether human beings have this ability

________b.f.skinner "Computer Science"

The SaaS model differs from traditional software not only in operational services, but also in the way and technology of software development.

How to develop SaaS software, what technologies will be used to develop SaaS software This is the main content of our research.

2 Key technologies to implement SaaS software

L SOA Technology

SOA and SaaS are not really the same as the twin sisters, SOA and SaaS are the two carriages of modern software services that run and keep abreast of the world.

Service Oriented Architecture (SOA) was first introduced by Garnter in the late 90, emphasizing the importance of services. The majority of consumers in the country through the SOA field of the boss of IBM's propaganda gradually to their understanding and understanding.

As time goes by, application software developers are increasingly involved in SOA, and it's no exaggeration to say that SOA is everywhere. As SaaS becomes more intense and SOA continues to deepen, Microsoft pioneered the "Software + Services" (S+s) strategy in the industry in December 2007 to open up multiple resources such as "internal business Integration (SOA) + external business Development (SaaS) + rich user experience" and "software" and "services" Organically combined to maximize it value, enabling SaaS and SOA to be both "fish and Bear paw".

According to Microsoft's definition in a technical white paper, "Software + Services" is an "it umbrella" that combines many of the existing technologies and theories of it, including SaaS, SOA, and Web2.0. With different manufacturers from different points of entry, the entire IT industry is holding up the "Software + Services" This big umbrella, to the future of it road.

"It environment is increasingly complex, so that people's demand for technology products is increasing, the next 10 years of technological development trend has been revealed that a single, modeled technology products or services will not meet the needs of social and economic development, the global science and technology ecosystem will be diversified, dynamic, service and other directions healthy development." Microsoft Academician, Microsoft CTO Office member Donaldferguson believes that in the service area, users can buy pre-trial, pay on demand, in the software domain, users have complete control-custom, one-time payment, how long you want to use. If a user chooses a pure software or a purely service approach, it is actually tantamount to giving up another advantage. "S+s" is a good solution to this problem. The concept of "s+s" is tailored to the diverse needs of users, with the option to access services, or to continue to own the software, or both.

"SOA is also very important for software vendors that are implementing SaaS." Interarbor Solutions, chief analyst at Dana Gardner, points out that SOA can help it deliver application software more efficiently. Moreover, they gain a competitive advantage in terms of price compared to traditional packaged software vendors.

Dr. Li Zhijian, Chief technology officer of Microsoft China, said that software and services played a complementary role in "S+s" and that 2008 will be an important year for Microsoft to step up its layout of the "S+s" strategy. According to Liuqin, SAP Business ByDesign Director, SAP will also take a big turn in 2008 and expand the new SaaS channel with SOA architecture products to reap the benefits of SaaS and SOA.

L Cloud Computing

SaaS as a new way of sales of application software has begun to flourish, but with the growth of SaaS software customers, network storage and bandwidth and other basic resources will gradually become a bottleneck for development, for many enterprises, the performance of their own computer equipment may never meet the demand, An easy way is to purchase more and more advanced equipment, and then it is the cost of equipment increases sharply, the profit decreases, there is no more cost-effective solution? " The advent of cloud computing may have opened a gap in the door for a solution to the problem.

Cloud computing (Cloud Computing) is a new way of sharing infrastructure based on the internet, typically for a number of large server clusters, including compute servers, storage servers, broadband resources, and so on. It takes advantage of the high-speed Internet transmission capability to move data processing from a personal computer or server to a server cluster on the Internet, which is managed by a large data processing center that allocates computing resources to customers ' needs and connects huge system pools to provide various IT services. To achieve the same effect as a supercomputer. Cloud computing centralizes all computing resources and is automatically managed by software, without the need for human involvement. This allows businesses to be more focused on their business and innovative, without worrying about tedious details.

Typically, SaaS vendors are more focused on software development, and less on network resource management, often waste a lot of money to buy infrastructure such as servers and bandwidth, but the user load is still limited, and cloud computing provides a simple and efficient mechanism for managing network resources, which allocates computing tasks, Workload rebalancing, dynamic allocation of resources, and so on, can help SaaS vendors to provide unimaginable huge resources to a huge amount of users, SaaS vendors can no longer waste their resources on the infrastructure such as server and bandwidth, and focus on specific software development and applications to achieve end-user, SaaS, The three-party cloud computing win.

This shows that cloud computing has considerable potential in the enterprise software market and is a great opportunity for SaaS vendors to choose a cloud computing platform, use cloud computing infrastructure, and use it at a low price to deliver more stable, fast, secure applications and services to a huge user base.

To get a quick grasp of the concept of cloud computing, we can use the concept of the cloud on the network frame composition. In the network frame composition, usually with work with to hide the Internet online architecture, you do not need to understand the complexity of the online, but can be simplified concept to communicate; The concept of cloud computing is to hide the complexity of the computing system so that developers do not have to understand the system architecture that provides computing resources. As long as the data of the operation is dropped into the system, the system returns the result.

Cloud technology can be regarded as a sub-collection of grid technology, the same purpose is to hide the complexity of the system, so that users can use the system without needing to understand how the internal workings.

L AJAX Technology

Ajax (Asynchronous JavaScript and XML) is a set of techniques for developing Web applications that combine programming techniques such as JavaScript, XML, DHTML, and Dom to enable developers to build AJAX-based Web applications. and breaks the convention of using page overloading. It allows the browser to provide a more natural browsing experience for users. Whenever an update is required, the modification of the client Web page is asynchronous and incremental. In this way, Ajax greatly increases the speed of the user interface when submitting Web page content. In an AJAX-based application, it is not necessary to wait for the entire page to refresh for a long time. The part of the page that needs to be updated is changed, and if possible, the update is done locally and asynchronously. Let the user enjoy the SaaS application service while can realize the local refresh of the page, using the browser-based b/s software, like using traditional C/s software as accustomed, smooth. Applications such as Ajax are being used in the software industry through SaaS.

L WebService Technology

Web Service is a SOAP-lightweight transport protocol, XML-encapsulated standard, HTTP-based component integration technology.

Web service is a kind of interface that is proposed to make the information between isolated sites communicate and share with each other. Web service uses a unified, open standard on the Internet, so Web service can be used in any environment that supports these standards (WINDOWS,LINUX). It is designed to be simple and extensible, which facilitates interoperability between heterogeneous programs and platforms, so that existing applications can be accessed by a wide range of users.

Soap technology is at the heart of Web service, encapsulating packets in the standard format of XML, where the encapsulated communication information is expressed in textual form and follows standard encapsulation rules. This means that any component models, development tools, programming languages, and application systems can use the technology as long as they support XML and text Format data. Now all component models, development tools, program languages, application systems, and operating systems support XML and text formats, and of course they can fully support soap.

In SaaS Software, WEB service provides a mechanism for communication between components. WEB service technology will greatly improve the scalability of the system, so that a variety of different platforms, different development tools of the application system seamlessly integrated. At the same time, soap, the core of Web service technology, is an open standard protocol, it not only breaks down the application barrier, but also can combine the enterprise firewall and internal information system, provide the security and integrated application environment, and allow the enterprise to encapsulate any custom information without modifying the source code of the application system. Provides a powerful system elasticity.

L Single Sign-on technology

One of the basic requirements for the ease of use of modern web applications, at least within our system, is to access all of the subsystems that he has access to, with the user logging in at once.

Single Sing is the ability to implement all authorized application systems that are automatically accessed through one login, which improves overall security and eliminates the need to memorize multiple login processes, IDs, or passwords.

In the WebService environment, single sign-on plays a very important role. In webservice environments, various systems need to communicate with each other, but it is impractical to require each system to maintain an access control list between them. Users also need a better experience to use the different systems involved in a business process without requiring tedious multiple logons and authentication. In WebService's single sign-on environment, there are systems that have their own authentication and authorization implementations, and therefore need to address the problem of user Trust mapping between different systems, and the need to ensure that once a user is deleted, the user will not be able to access all participating systems.

SAML is a standard that encodes authentication and authorization information in XML format. A Web service can therefore request and receive SAML assertions from a SAML-compliant authentication and authorization service, and thus authenticate and authorize a service requester. SAML can be used to pass trust-like between multiple systems and thus be used in a single-sign-on scenario.

3 product line production of software factory

By applying important new approaches, it is possible to overcome the economic and technical problems that impede the transition from technology to production, which have taken new approaches in dealing with complexity and change. These new approaches are also present and show significant potential in terms of commercial products, although most are immature. Mainly in four aspects: System reuse, assembly development, model-driven development, process framework. Let's consider each of them individually.

L System re-use

One of the most important new methods in software development is to define software product families, whose members are changing, but share many common features. Like Parnas, such a family provides an environment in which the common problems of members can be collectively resolved. By identifying and distinguishing features that are more or less present in multiple products and those changes, we are able to use a systematic approach to reuse. A software product family consists of components or the entire product. For example, a family should contain different application investment management, including different user management frameworks, and the user management framework is used by application investment Management and user relationship management applications.

The SOFTWARE PRODUCT family is developed by the System Integrator (SIs), from a user to a user porting application, or by improving an existing application to create a new application. They also develop software product families through independent software vendors, develop regional multi-application like CRM, or multi-version applications through maintenance and improvement. They also develop software product families through IT organizations, improve existing applications, develop multi-relational applications, or multi-version applications through maintenance and improvement.

L Practice of software production line

Software production line development software product families, through the identification of common characteristics and fill in special field changes in the form of the SOFTWARE product family members of the development of a faster, cheaper, less risk. Rather than hoping for temporary reuse, they systematically capture how to develop the knowledge of family members, making the reuse of assets possible and exploiting those assets in the development process of family members. As a family product development, it is possible to reuse requirements, architectures, frameworks, components, tests, and other assets.

Of course, it costs to develop a production line. In other words, the line embodies the classic cost-benefit tradeoff. While the benefits of the equation cannot be increased by producing many backups in a market that supports limited releases, it is possible to increase profitability by producing many related, unique products, as described in many case studies [CN01]. The use of software production lines is the first step toward software industrialization. Making them more inexpensive to create and run is the second step. Figure 1 describes the execution of the main tasks, the production and utilization of the workpieces on a production line.

　　

Figure 1 Software production line

Production line developers apply development assets to develop software family members in the same way as platform developers create device drivers and operating systems for use by application developers. An important step in developing product assets is to develop one or more regional models that describe the common problem characteristics and descriptions of the different tables provided by the production line. These models collectively define the scope of the production line and are used to qualify the intended members of the software family. The requirements of the members of the software family are derived from these models, which provide a way to relate the changes in requirements to the changes in the architecture, implementation, execution, development process, project environment, and other parts of the software life cycle.

L Model-Driven development

Raising the level of abstraction is an important process that reduces the scope of abstraction and thus reduces the developer's control when implemented. Loss of control is the corresponding increase in power. Most business application developers, for example, prefer to use a higher level of abstraction like these in the C # and. NET Framework, rather than assemble the language and system calls. Higher levels of abstraction produce many benefits, including higher productivity, fewer defects, and easier maintenance and improvement.

Unfortunately, we see improvements in abstraction levels and tools that are very expensive. If we can find some way to make it faster, cheaper, and easier, we can provide a higher level of automation for small problem domains. This is the goal of model-driven development (MDD). Model driven development and utilization model flooding captures high-level information, usually informally, automatically, either by compiling a model or by making it easy for manual development to be performed. This is important because the information is currently missing from the lower-level artifacts, such as source code files, difficult to track, maintenance and continuous improvement.

Some development activities, such as build, configure, and debug, are now partially or completely automated by leveraging information captured from source code files and other implementation artifacts. Using the information captured through the model, MDD can also provide more scalable automation activities, as well as more automated optimization tables, such as model debugging and automation configuration tools. Here are some examples:

² daily tasks, such as producing another thing from one thing, are usually fully automated. For example, test appliances can often be automatically produced from user interface models, which translates between pages to simulate user activity.

² Other tasks, such as solving the differences between artifacts, can be partially automated. For example, the columns in the table and the fields in the form may be full of problems to be solved by the user, and then the user decides to automatically correct them.

² adapters, such as Web service wrappers, can be automatically generated from model-to-bridge differences in the implementation technology. The model can also be used to represent, protocol configuration, and other adaptive integration mechanisms.

² models can be used to define artifact configurations, which are composed of configuration units that automate the configuration process. The configuration environment of the model can be used to constrain the design so that the design can be implemented correctly.

² models can be used to describe the configuration of configuration parts, capturing information about operational characteristics such as download balancing, failure recovery, resource allocation strategies, automated management activities, data collection and reporting.

L Specific Domain language

For MDD, we are no longer interested in some end languages such as 4GLs, nor are we interested in using a high level of language for all aspects of development. Weaknesses in these strategies have been amply demonstrated. We are also no longer interested in the models presented at the meeting, as well as notes. Unfortunately, models are often used to make files for people to use instead of computers. This creates the impression that the model is not the first type of development artifact with source code. We are interested in using tools to process models, and we plan to use them in the same way as source code. In this way, the model of a document design cannot be expressed in words. The model must be accurate and unambiguous. At the same time, in order to improve the level of abstraction, the modeling language must focus on small areas rather than a common programming language. Have the following requirements:

² The goal of language design must be clearly defined so that the reviewer in the field can evaluate the language and determine whether it achieves the goal.

² This language must be able to enable people working in this field to capture business concepts. The language used to develop and assemble Web services must contain concepts such as Web services, Web methods, protocols, and protocol-based connections. Similarly, a language used to visualize and edit C # source code must contain concepts (like C #), such as classes, members, domains, methods, properties, events, and proxies.

² This language must familiarize its users with the names of their concepts. For example, a C # developer discovers that a model of a class that owns a domain and a method is more natural than a model that has a class that owns properties and operations.

² The symbol of language, is a picture or text, must be easy to solve the problem. What people do everyday must be easily expressed in terms of concepts. For example, it must be easy to manipulate an inheritance in a visual and C # source code editing language.

² This language must have a set of well-defined rules, called grammars, to manage the expressions that make up the concept. This makes it possible to use tools to detect whether an expression is correct, and to help the user write concepts.

² The semantics of each expression must be well defined so that the user can create a model that others understand, and the tool can produce a legitimate implementation from the model, and the metadata captured from the model can do what it expects when it is used to handle tasks, like configuring the server.

Languages that meet these criteria are called domain-specific languages (DSLs) and should be modeled for those specific domain concepts. DSLs are more restrictive than general modeling languages. Like a programming language, it also has text or picture symbols. Sq and HTML are two examples of DSLs, respectively, for relational data definitions and Web page definition services.

Figure 2 is an example of two illustrations illustrating a DSL, which is a screen of Microsoft Visual Studio 2005 Team System. The DSL on the left describes the components, like Web services. It is used for component development and configuration automation. The DSL on the right describes the logical service type of the data center. It is used to design and implement data center configurations. Web service development is done by dragging the service parts onto the logical server. The difference between resource requirements and availability on a logical server is filled with confirmation errors and illustrations.

　　

Figure 2 Domain-specific languages

L Incremental Code generation

The key to efficient code generation is to produce less conceptually small-difference code. This allows the tool to take advantage of platform features, producing centralized, efficient, and platform-specific implementations. One way to add more code generation is to get the model closer to the platform, as shown in 3. For example, a specialized programming language defined with a programming language type system can be modeled more realistically than a modeling language defined using a type system. The model now becomes a code view, and the developer graphical operator structure is like the operation class and method definition. This tool embodies the relationships and dependencies that are hard to see in the code, saving time and effort to generate code for the program structure. It enables the implementation of a programming style like relationship-based collection, or provides advanced features like repro and pattern construction, application, and evaluation.

　　

Figure 3 SaaS Operation Human Relations Group

Of course, by restricting abstraction on the available platforms, this weakens the role of modeling, or does not work much like a programming style. So how do we work at a higher level of abstraction? We used a more abstract model, using frameworks or transformations to make the platform and model more compact, as shown in 4. Let's take a look at these.

　　

Figure 4 Programming language Modeling

Using high-level abstractions

² We can use the framework to implement the high-level abstraction in the module, using these modules to generate small pieces of code at the frame extension point. Instead, the model helps the user complete the framework by visualizing the framework concept and embodying the extension in an intuitive way. When you start using Microsoft's operating system, such as building graphics applications is difficult. Microsoft Visual Basic then makes it easier to apply graphics by using forms and control concepts.

² We can create a lower-level DSL description Language instead of a schema or model language. To lead this revolutionary change, we can also use more than two DSL description languages to span a wider span, and models described in the highest-level DSL language can be transformed into executable soft, 4. This illustrates how the compiler works, translating high-level languages like C # and Java into intermediate code like bytes or IL, which are JIT-compiled into the binary format of the target platform.

L Composition mechanism

Of course, handwritten code must usually be combined with the framework code to produce a complete executable program. A number of different mechanisms can be used to do these things. The important difference between them is to help set the time.

　　

Figure 5 Composition of the design time

The two advantages of runtime binding are that the interface enables the combination of handwritten and framework code, allowing for dynamic configuration through object substitution. At the same time, the delegate class allows handwritten code to be protected by regeneration. A relatively small drawback is that the runtime is often a method call. In the component programming model, some mechanisms based on runtime binding are very popular, as shown in 6. They are very successful in large-scale commercial products.

² before compiling, the design time in the same artifact is mainly the time of both the handwritten code time and the frame code, as shown in 5. This includes the constraints of editing experience to avoid user modification of the framework code (for example, with a read-only region editor). In other tools, users add handwritten code in a special window. With asynchronous callbacks, the runtime bindings merge handwritten and skeleton code. An agent-based runtime binding mechanism is described through a design model, such as the following from Gamma,et.al.:events (Observer), Adapters (Adapter), policy objects (strategy), Factories (Abstract Factory), Orchestration (mediator), wrappers (Decorator), proxies (Proxy), commands (Command), and? Filters (Chain of Responsibility) [GHJV95]. The two advantage of runtime binding is that the interface enables the combination of handwritten code and framework code, allowing for dynamic configuration through object substitution. At the same time, the delegate class allows handwritten code to be protected by regeneration. A relatively small drawback is that the runtime is often a method call. In the component programming model, some mechanisms based on runtime binding are very popular, as shown in 6. They are very successful in large-scale commercial products.

² handwritten sub Class. The user provides handwritten code in the sub class in the frame. The abstract method in the framework code defines the display overlay point. For example, the user writes a subset of the framework entities, referencing the handwritten code in the domain through a template method pattern, and highlighting function calls.

² Frame Sub Class. The user provides handwritten code in the parent class of the framework code. An abstract method of handwritten code is overridden in the framework code. For example, a framework entity field introduces a parent function call about handwritten code, and a prominent function call.

² handwritten delegate class. The user supplements the write code in the delegate class. For example, a framework entity invokes a handwritten entity at the point of development, before or after setting a property value. is actually a proxy server mode.

² Framework Delegate Class. The user complements the handwritten code to obtain the framework service. For example, a handwritten code entity invokes a framework entity to set or get a property value.

　　

Figure 6 Run-time composition

² Bind the merged handwriting code and framework code during compilation, as shown in 9. It is a good way to take advantage of partial specifications and compile-time merging during compilation. The Visual Basic and C # languages in Visual Studio 2005 are compiled during compilation.

　　

Figure 7 SaaS Operation Human Relations Group

L Assembly Development

Important innovations in the field of platform-agnostic protocols include, self-describing, variable encapsulation, process-driven development through assembly and architecture.

L Platform Agnostic Protocol

Web Service technology has been successful, and early component assembly techniques have failed to isolate specific and assembled components from the implementation technology. Because XML is a technology for managing information, not a technology for building components, Web services use encapsulation to map Web method calls to local method calls, based on the following component implementation techniques. Although CORBA attempts to use a similar strategy, its complexity requires a substantial investment by the platform's suppliers, which limits its scope of use. Simple XML-based protocols significantly reduce the difficulty of implementation and ensure their universality. By encoding remote method call requests like XML, they avoid the cooperative work problems caused by the special remote call coding and parameter aggregation of the platform. At the same time, they have designed the collaborative capabilities of the platform from the outset by gaining a wide range of industry standards.

L Self-description

By improving the packaging of components to make inferences, dependencies, behaviors, resource consumption, performance and proof apparent, self-description reduces the scenario of a schema mismatch. It provides metadata that can be used to automate component discovery, selection, licensing, acquisition, installation, tuning, assembly, testing, configuration, deployment, control and management.

The most important form of self-description is to describe component inference, dependencies, and behavior, so developers can roll out interactions between components, and tools can validate the assembly. In object-oriented use to a wide range of spec sheets is the class and interface declaration. They define the behavior provided by the class, but by naming other classes and interfaces in the method signature, only important inferences and dependencies are explained. The contract is a rich specification. A contract manages the interactions between components. It does not know when to invoke a component. A contract describes the order of interactions, and responds to protocols that are illegal and other unpredictable conditions.

Of course, contracts are not used unless they are forced. There are two ways of enforcing contracts.

² assembly of components without mismatched contracts

² provide the adapter with the information provided by the contract, which allows the components to interact directly between them, or to coordinate their interactions.

Garlan recommends using standard adaptation technology recipes and providing tools for encapsulation and data conversion [Gar96]. One of the most promising adaptation strategies is the release of a subset of components that can be completed during assembly by encapsulating various aspects that provide the code needed for the assembly. This strategy, called variable encapsulation, is described below.

Another important aspect of self-description is proof. If the component can prove that there is only a specified dependency, consumes the specified resources, has specific functional characteristics under certain conditions, or has some public weaknesses, it can infer the functional characteristics and operational characteristics of the software assembled by these components. This has been studied in the Software Engineering Institute at Carnegie Mellon University and is considered to be a predictable assembly of guaranteed components (PACC).

L Variable Encapsulation

As we have seen, static encapsulation reduces the possibility that a component can be used in a particular assembly by statically binding its functional aspects or the intrinsic aspects of a function or an upper or lower correlation. Variable encapsulation reduces the mismatch between architectures by releasing partially encapsulated components that, by leveraging their functional aspects, select and develop appropriate non-functional aspects, enabling the ability to adapt to new context relationships, as shown in 8. The form of a component in a particular assembly can be determined by the context in which it is located. Flexibility can be improved by making component boundaries more resilient, and by reducing the mismatch between architectures. By removing the functional hypothesis, the functional part is allowed to be re-made on the component boundary. Effective adjustments can be pre-identified and, in some cases, can be done automatically by means of tools.

　　

Figure 8 Variable Encapsulation

Variable encapsulation is a rewrite (AOP) for tangent-oriented programming. AOP is a method of separating and combining the different aspects of a system [KLM97]. Variable encapsulation differs from AOP in three ways.

² variable encapsulation is included in the encapsulation aspect, but AOP, as a common practice, is programmed into non-encapsulated lines of code. In non-encapsulation, the same problem arises when assembling a poorly packaged package, called architecture mismatch and unpredictability. Indeed, the source code based on aspects is more inclined to these issues rather than component assembly because the components have at least a description of the behavior and some protection from the non-dependent wrapper. The lack of packaging for AOP makes it difficult for developers to infer the compatibility and functionality of a feature, or to perform the resulting feature, almost making it impossible to incorporate tool inspection aspects.

² AOP is programmed during component development, but variable encapsulation is programmed later than they are, such as during component assembly or configuration. This is important because the context in which the component might be placed is not known until the component is published. In fact, in order to support assembly development, as the article describes, the third part must be able to anticipate the assembly and deployment of non-dependent development components. This requires a formal way to partition aspects, encapsulation aspects, description aspects and packaging aspects. Variable encapsulation can also be progressive, and it can occur at different stages. For example, we can bind some aspects during the assembly, some aspects during development, some aspects during the run.

² variable Encapsulation is architecture-driven, but AOP is not. The aspects that are separated from the functional kernel must be clearly defined by interfaces, abstract classes, WSDL files, or other forms of contract.

L Process Management Assembly

If there is sufficient contractual mechanism, services can be managed through the process management engine, such as Microsoft BizTalk Server, to manage the order of information exchanged between them, as shown in 9. Process Management assembly makes Assembly development easier because the dependencies between services are much less than binary components. Unlike classes, they do not need to reside in the same execution. Unlike components, platform-specific protocols are required, and they can be assembled through platform boundaries. If the contract between them is compatible, the two services can interact with each other. They can be developed and deployed separately, and then assembled through process management. If proper interception of the heavy-channel service is available, they can even reside in different management and organizational areas. In other words, the process management assembly eliminates the design, compilation, and deployment time dependencies between different components.

　　

Figure 9 Process Management assembly

The process management assembly is essentially a quorum, as described in the Gamma Arbitration model. An interaction process between the quorum management component. A quorum has powerful properties. One of the functions is to filter or translate the information when the component interacts. Another function is to control the interaction and, if necessary, to maintain the state through a multi-channel adjustment. This allows the arbitration to infer the interaction, which can be changed by conditional logic if necessary. Arbitration can also perform useful functions such as logging, enforcing security policies, different technologies, or connecting different versions of the same technology. A quorum can also be a functional part of the Assembly, reinforcing business rules or performing business functions, such as reaching commercial transactions.

L Architecture-Driven development

When it is better to prevent assembly of mismatched components than to build illegal assemblies, there is no need to improve the availability of matched components. This is the goal of the architecture. According to Shaw and Garlan, a software architecture describes the assembly of components, their interaction and acceptable composition patterns, reducing the risk of well-designed architecture mismatches and constrained design decisions.

Of course, developing a software architecture can be challenging. This allows many architects to spend many years mastering limited architectural style or application areas. Without greater trust in architectural practices and in software architectures, assembly development cannot be achieved on an industrial scale.

These are the goals of architecture-driven software development (ADD), including:

² standards for describing, retelling, and using architectures.

² A method for predicting the utility of design decisions.

² mode or architectural style, it is used to organize the design expert opinion, help the designer to develop the component split reproduction mode.

An architectural style is a rough model that provides a set of family systems to the abstract framework. It defines a set of rules that specify different kinds of components that can be used to assemble a system, and the relationships of different kinds of components can be used in assembly, assembly constraints, and assembly assumptions. For example, a Web service composition style can be used to specify a component to provide a port. These components are defined by the Web service and are connected via a connection port, only two ports are compatible to connect and communicate with soap over HTTP. Other architectural styles include: Data flow, layering, and MVC style. An architectural style facilitates partitioning and improved design reuse by providing solutions that are frequently problematic, as well as the following.

² reuse is achieved by identifying common architectural elements, which are based on this style and are shared by the system.

² to express Understanding by defining a standard framework.

² improve the ability to work together by defining standard communication mechanisms.

² Improve visualization by defining standard representations.

² to improve tool development by defining mandatory constraints.

² analysis is done by identifying the system's salient features based on this style.

An architectural description is a document that defines a software architecture. IEEE Standard 1471, which is recommended for describing intensive software architectures, provides guidelines for describing the architecture [IEEE1471]. According to these guidelines, a system has one or more shareholders. A shareholder has special concerns and interests in certain aspects of the system. In order to be useful to shareholders, an architectural description must require a form and structure that enables shareholders to understand. Ads is a template used to describe the architecture of a system family. A formal scenario defines a view that describes a part of a software product, and it also provides a pattern for describing, defining scopes, goals and audiences, custom languages, and the methods used to develop it.

These salient elements are used to specify a scenario that includes:

² an identifier and other introductory information (e.g., author, date, reference file, etc.).

² Stakeholder relationship with the scene.

² Custom, language, and scenario-based methods for generating views.

² Confirm the consistency of the view and complete the test.

A view describes a software product from a given scenario. A view is semantically close, meaning that it describes a software product from that scene. A view consists of one or more artifacts, each of which is developed according to the requirements of the scene. A view is an instance of a scene that must be consistent with the scene for a better forming view. A view follows a Web page design scenario, for example, a page layout that should describe a particular software product, which should describe the layout of a Web page with a well-defined symbol. These salient elements are used to specify a view that includes:

² an identifier and other introductory information (e.g., author, date, reference file, etc.).

² The scene identifier that the view follows.

² Software PRODUCT Description constructed using custom, language, and scenario-defined methods.

To understand the view and its scenario differences, consider logical database design for commercial applications. Logical data

A library design is a view of an application, or, more specifically, a view that makes up a component. Both the application aspect and the language used to describe it are defined in the logical database design scenario. Many different business applications can be regulated by using the same scenario, resulting in different views, each describing a logical database for some commercial applications. These views can describe the same aspect, in the same language, but they will have different content, so each content describes a different application. An assembly view can break out the views of individual components from the same scene.

According to IEEE1471, an architecture description must identify the scenarios used and the rationale for using those scenarios. Ads, as a special goal, can be defined by enumerating the set of scenarios in which they are used. For example, ads for a consumer-to-business Web application may require a scenario for page layout and a scenario for the layout of business data. Each view in the schema description must follow a scenario defined by ads.

L Process Framework

As project size, geographic distribution, or time and complexity increase, the key to maturity is to maintain flexibility. Experience has taught us that few structures increase flexibility by reducing the amount of work required. This principle can be applied in the SOFTWARE product family, using the process framework to manage complex products without reducing flexibility.

Some of the difficulties with the formal process are that they are too abstract. The guidance they provide is obvious to older programmers, but not very specific enough for beginners. To add value, it must reduce the details of the current project, because each project is unique in many ways and it is impossible to produce a process that satisfies all projects. We know how to solve such problems, and we can tailor and cut out a formal process for a special product family. If there are no professional suppliers, the above things can not be successful in the market. Some vendors are often adding something useful from other processes such as XP in order to customize the process for special users. Other, especially system integrators and ISVs, tailoring processes to suit specific product or consulting practices. In every way, the key to efficient use of any process is to make it highly specialized for a given project so that it contains only directly available resources. The changes produced by this customization are very complex and result in very few similarities to the original process.

A highly centralized process includes detailed project information, such as tool configuration, network share paths, developer-guided work, API documentation, key links to critical process names like cm, bug tracking and processing, group strategy on check-in, programming style and peer check, There are other details about the project and the project team. Together with other forms of system reuse, this customization will be useful only if we can use it more than once. Similarly, reusing a highly centralized process resource increases its flexibility by eliminating work, just like any other reuse resource. As Jacobson often says, the quickest way to build things is to reuse something that already exists, especially reusable resources that can be customized and extended. Many things can be reused in a systematic way, and the development process is the same.

A process framework is decomposed into smaller processes that enclose the ads scene. Each small process describes the need to generate a view. It is able to enumerate key decision points, identify the transformation links for each decision point, describe the necessary and optional activities, describe the resources required for each activity, and produce the product. There are some constraints before each workpiece processing, and some post-conditions, the desired constant environment when the workpiece is stable. For example, we need to get the loop condition before the loop starts and get the end condition when we exit. We need all the code to be built and tested correctly. We call this architecture a process framework because it defines the space for possible consolidation processes, relies on the needs and circumstances of a given project, and does not necessarily describe a process for all projects. When a process framework is defined, a small process can be combined into any workflow required by the project, including top-down, bottom-up, from inside to outside, test coding and coding tests, any combination or mixed streams.

These workflows can be driven by resources, allow for optimization through PERT and CPM, and start a workflow when resources are available. Many kinds of resources can drive plans, including requirements and source code, developers and program managers, configuration management products, or bug tracking systems, such as opening a port on a server or allocating storage to a device. This is called a constraint-based plan. Constraint-based planning leverages a small number of architectural requirements to balance the need for flexibility. Constraint-based planning provides guidance for adding constraints to development artifacts rather than the prescribed process. The generation of flexibility can be generated dynamically through a workflow in constraints, adapting to a large number of environment variables, while summarizing learning experience and reducing the cost and time of knowledge re-discovery.

A process framework does not need to be too large or too small, and may contain more or less detail. This provides a way to measure the size of a process, depending on the environment. For example, a small, flexible team can use a small framework that only provides some of the main key practices, such as XP. A large organization can add many details of the build process, examine the process, test the process, or share the rules of the component.

4 Summary

This article describes the development model of SaaS. By introducing the key technologies that enable SaaS software, we have a purposeful understanding of this knowledge. The production line of the software factory originates from the traditional manufacturing industry, and it is not impossible to realize the factory of the software in the process of the manufacturing pipeline. When it comes to the development of the system architecture, software architecture is mainly the layering of software. In this section, both. NET and Java EE illustrate the architecture of the software through examples. Product development is not only the technical road but also the decision-making problem of enterprises. Different companies can adopt effective and optimal research and development mode according to the actual situation of the company. Building and accumulating your own development system can help you reuse your code and greatly reduce your development costs.

SaaS Series Introduction 14: SaaS Software Development Analytics