Service-oriented analysis and design principle
Written / Olaf Zimmermann, Pal Krogdahl, Clive Gee
The experience of the initial service-oriented architecture, SOA implementation project shows that object-oriented analysis and design (Object-Oriented Analysis and Design, OOAD), Enterprise Architecture, EA framework and business Existing development processes and representations such as Business Process Modeling (BPM) only covers some of the requirements required to support the architectural mode of the architecture in SOA. In Info World's nearest interview, Grady Booch claims that "the foundation is never obvious like a good abstraction and good separation of the problem", but he also pointed out: still has a realistic opportunity to increase the abstract level. Past experiences have shown that the abstract levels must be increased to the company's processing, thus incorporating the entire enterprise IT prospects into consideration. Just as Mark Colan introduced in article "Service-oriented System Structure Extended Web Services, SOA is an emerging corporate structure that can be used to design next-generation enterprise applications. SOA methods have added some other topics, such as information hiding, modularization, and problem separation, as well as information hide, modularization, and problem separation, such as service arranging, service libraries, and service bus intermediate parts. Structured methods or analysis and design methods are required to design high quality SOA. Because there is no such existing method to meet the requirements of the programming staff to the latest SOA project, they recommend the principles of good practices (such as OOAD, EA and BPM), and use as needed to innovate The principle is supplemented.
Introduction The basic concepts of service architecture (SOA) and web services will become part of our daily language and can be seen as an architecture suitable for designing modern enterprise applications. In this context, what makes this basic problem makes it a key to ensuring SOA to ensure successful implementation. Object-Oriented Analysis and Design, OOAD, Enterprise Architecture, EA) Framework and Business Process Modeling, BPMs provide us with existing modeling rules for us High quality practices can help identify and define appropriate abstractions within the architecture for a long time. However, experience shows that these practices are not required to be applied separately. In this article, we will study the appropriate principles in OOAD, EA, and BPM. We will also promote the needs of the mixing method, this method combines all the principles in these rules to many unique new principles. The cross-discipline OOAD method thus obtained makes it easier to successfully develop SOA development, and we call services - Oriented Analysis and Design, SOAD, it still needs to be officially defined. We are just just into the hall of SOAD.
The SOA architecture form is intended to provide an enterprise business solution under the expectation of new business opportunities or threats. These business solutions can be extended or changed as needed. The SOA solution consists of reusable services, with a promising interface that is well-defined and compliant with standards. SOA provides a mechanism that can integrate existing legacy applications through this mechanism, regardless of their platform or language. Conceptually, there are three major abstract levels in SOA: l Operation: represents a single logical work unit (LUW) transaction. Execution operations typically cause read, write or modify one or more persistence data. The SOA operation can be directly compared to the object-oriented method. They have a specific structured interface and return to structured responses. Like the method, the execution of a particular operation may involve invoking additional operations. l Service: The logical grouping of the representative operation. For example, if we treat CustomerProfiling as a service, follow the telephone number to find customers, listed by the name and postal coding, and save the data of the new customer, represent the relevant operations. l Business Process: A set of long-term operational actions or activities that implement a specific business goal. Business processes typically include multiple business calls. Examples of business processes are: accept new employees, sell products or services and complete orders. In SOA terms, business processes include a series of operations executed in accordance with a set of business rules. Sort, select, and execution are called service or process arrangements. A typical situation is to call the procedured service to respond to business events. From the viewpoint of modeling, the challenge is how to describe the characteristics of well-design, service and process abstract and how to systematically construct them. These related issues are the most commonly discussed problems in the current industry and academia. As far as we know, almost all SOA projects or topic seminars will use such service modeling as an important topic and have caused many arguments. Therefore, let us look more about it.
Why is BPM, EA and OOAD are not enough? Early SOA implementation project experience shows that existing development processes and representations such as OOAD, EA and BPM only cover some of the requirements required to support the SOA paradigm. While strengthening the principles of good general software architecture (such as information hide, modularization, and problem separation), the SOA method has added additional topics, such as service arranging, service libraries, and service bus intermediate parts. The model needs to give special attention to them. Figure 1 shows the main application areas of existing EA, BPM, and OOAD modeling methods, and we will then discuss the starting point of SOAD. The horizontal axis in the figure represents the life cycle stage of the project; the vertical axis represents the difference between the different abstraction layers or the field, and modeling activity is usually carried out. The vision of SOA is quite easy to understand because it is well known. For example, in any SOA work, application general software architecture principles and OO technologies are a valid start. However, as we have mentioned, the problem of early adopters the most common question is how to identify the correct service. As mentioned earlier, OOAD, EA and BPM do not provide satisfactory answers when they are independently applied, and this is exactly what we need to explain now. The OOAD method described in the groundbreaking book written by Booch and Jacobson (published by the Object-Oriented Software Engineering: A Use Case Driven Approach) provides a very good starting point in defining the SOA. Similarly, although the use of OOAD Technology and Unified Modeling Language, UML in many years is a common practice, OOAD is still a micro level like a class and a separate object instance. Abstract related. Since each problem domain often creates a separate operating model, the application development project, the large direction of this company becomes blurred in many cases. In addition, due to various reasons, the conditional model is not always synchronized with its equal BPM. Treasury Enterprise Architecture Framework, Teaf, http://www.software.org/pub/architecture/teaf.asp / www.sei.cmu.edu/domain-engineering/foda.html) and Zachman (http://www.zifa.com/) EA method plus urban planned views above the solution architecture However, there is no problem with how to find a high-quality business that is easy to reuse and has persistent. Although the BPM method (such as bpmi, http://www.bpmi.org/) provides an end-to-end view on the functional work unit, they usually have no architecture and implementation. For example, language appears in languages such as business processes like a Web Services (Business Process Execution Language for Web Services, BPEL, http://www.research.ibm.com/journal/sj/412/leymann.html) Previously, the BPM representation lacks the operational semantics. In addition, we have also seen many processes modeling and development activities separated from each other.
Finally, there is no problem with existing rules that can resolve how to enable existing applications for SOA; most of the time uses the top down process. Existing systems typically store large amounts of important data and business logic, and cannot be simply replaced. Therefore, in order to study packaging and reconstruction strategies, these systems must be analyzed from bottom to bottom. Therefore, considering existing applications will bring us to the process of encountering. Due to the presence of these reasons, it is necessary to mix the SOAD modeling method. This approach combines the principles in OOAD, BPM, and EA in the best way, and integrates some innovative principles. Figure 2 shows the SOAD resource (principle and technique of this new method): EA develops enterprise applications and IT infrastructure into SOA may be a big burden, which will affect multiple traffic lines and organizational units. Therefore, it is necessary to apply EA framework and reference architecture (such as open tissue architecture framework, THE OPEN Group Architecture Framework, Togaf, http://www.opengroup.org/architecture/togaf), and Zachman to strive to achieve separate solutions Consistency between architectures. Based on past experience, most existing EA frameworks are limited in one or more aspects. For example, if the main problem is to indicate how the low-level block of the technical device is interconnected in a macro hierarchy, the business layer process or service view is not available. However, in the context of SOA, this way to consider problems must be converted to a logical component representing the business service, and focusing on interfaces and service level agreements between defined services (Service Level Agreements, SLA). In addition, many enterprise-class reference architecture and framework are quite ordinary and have not touched the design area. Such advanced architecture cannot provide specific tactical advice for architects and developers, and often lead to fundamental differences between enterprise architecture and solution architecture. SOAD must help the SOA architect define the overall business level view of the service prospect. This is what today's EA framework is unable to provide SOA-specific enhancements in the future; on demand Operating Environment, Odoe, http://www1.ibm.com/partnerworld/pwhome.nsf/ Weblook / ebod_environment.html is the main strategy for IBM for this trend.
BPMBPM is an incomplete rule, which has many different forms, representations and resources. Another commonly used technique is to define an event-driven flow chain representing a conceptual flow stream, which uses a representation different from the UML. In addition, many dedicated methods such as BPM can be considered as a competitive advantage by the Enterprise Resource Planning, ERP package manufacturers. ARIS Implementation Platform is an example of such a product. Other methods include: Line Of Visibility Enterprise Modeling (LOVEM) and IBM Component Business Model (CBM) strategy. The most recent trend is to define a standard method that represents the executable stream model, such as business process Execution Language for Web Services, BPELs, for web services. BPEL expands the scope of the process from analysis to implementation. Such an executable model has triggered a series of new problems, including: l which aspects should be described in BPEL, what should be described in WSDL? Where is the difference between the process model and the traditional programming model? l How to join non-functional requirements and quality of service characteristics into the model? l How much logic is executed in the programming language extension of the BPEL engine as compared with more traditional encodings (eg, in J2EE)? l How to assess the quality of the executable process model, what is the best practice of its application? l What work character is carried out by BPEL streaming; Is it a business expert (analyst) or development role (software architect)? All existing BPM methods must be used as the starting point of SOAD; however, it is necessary to use additional techniques for driver candidate services and their operations in the process model to supplement them. In addition, the process modeling in SOAD must be synchronized with the design layer production, and must give the answer to the BPEL.
OO paradigm and service (SO) paradigm OO analysis are a very powerful and widely praised method. Soad should use OO analysis technology as much as possible. To successfully apply OO to SOA project, you must analyze multiple systems once. The condition model must continue to play an important role. However, SOAD must be the process, not the user driven. Therefore, SOAD requires strong links between BPM and production modeling activities. In the design layer, OO's goal is to make quick and efficient design, development, and perform flexible and scalable applications. Objects are software constructs, their behavior is like their real-world entities that model them. For example, a customer will have a name and contact information, and there may be one or more account objects associated with it. From OO's perspective, everything is an object. The basic principle of OO is: l Package: Software object is a discrete package that contains physical properties (data) and functional (behavior) of the objects of the real world. For example, an account object maintains a balance of payments and includes borrowing mechanisms in balancing. l Information Hide: Structure Good object has a simple interface and does not draft any internal mechanism to the outside world. Examples of real-world information hidden are, you don't need to learn more about the working principle of your car. L and instances: Class is a template for defining a particular type of software object has what type of properties and behavior templates, while the instance is an individual object with these attribute values. The new instance of the creation class is called instantiation. With biology, people are a class. All people have some properties, such as height, weight, hair and eye color, and so on. Everyone in us is this class humanbeing instance, with some specific height, weight, and other attribute values. The class is always existing, and the example has a limited life cycle. l Association and inheritance: The ability of the association between the expression and objects is a key concept; inheritance is the strong form of association, used to express relationship: according to the same manner, biological species consists of such a hierarchy : Kingdom, PHYLUM, Class, ORDER, Class, Class, Spectia. We often find the natural level of the software object. For example, when you create a financial application entity, you may need to construct an object like a Crestking Account, a Savings Account, and a loan account (Loan Account). If you look more carefully (see Figure 3), you will discover these classes to share many properties, such as balance balance accounts, debit accounts, and credit accounts, and more. Repeat and manage the code for these attributes, it is better to create a universal account (Account) class, which has cash balance and can handle lending. All other classes are the special form of this account (Account) class object. For example, a loan account will have a negative balance between zero and an agreed maximum, while saving account (Savingsaccount) will have a negative balance and will show the behavior of increasing interest, and so on. l Message Pass: In order to complete some useful work, the software object needs to communicate with each other. They do this by sending messages with each other.
For example, suppose we want to transfer $ 1000 from a regular account to a savings account, to reach this, you can send a message with parameter $ 1000 to the CHECKINGACCOUNT instance, and send the corresponding loan message to the savings account (Savingsaccount Example. When an instance receives a message, it performs the corresponding function, referred to as a method, which has the same name as the message. l Polymorphism: This term describes two or more classes to accept the same message but implemented in different ways. For example, a freecheckingAccount instance and a CHECKINGACCOUNT instance will respond to borrow ($ 100), but the freecheckingAccount instance will justify $ 1000 to record its account balanced debit, and CHECKINGACCOUNT The instance adds $ 1000 to the transaction fee into its account balanced branch.
OO supports the complete lifecycle of application analysis, design, and development: l OOAD tries to find the best object and the most natural class inheritance to achieve them. L OO development focuses on progressive development of the application, each implementing a business scenario or use. Tools like IBM WebSphere Studio Application Developer help developers quickly construct and test OO applications. L OO runtime environment, such as provided by Java virtual machines, providing application services (such as garbage collection (deleting resources that use their objects have been discarded)) and framework (such as J2EE) to reside Objects on different servers provide mutual communication mechanisms. The main problem with OO design practices related to SO is that its granular level is concentrated in the class, and this abstract level is too low for business service modeling. Such a strong correlation such as inheriting has produced a certain degree of tight coupling between the relevant parties (therefore has dependence). In contrast, the SO paradigm attempts to promote flexibility and agility by loose coupling. Currently, there is no service instance cross-platform inheritance support and first-class representation in SOA to avoid processing service lifecycle maintenance management issues (such as remote garbage collection). These considerations make OO difficult to maintain directly with the SO architecture style. However, for the underlying layer class and component structure in the designed service, OO is still a valuable approach. In addition, many OOAD technologies (such as classes, responsibilities, collaboration (CRC) cards can also be used in service modeling (if they are upgraded to higher levels). Before this article, we will go back to discuss this. Figure 4 shows the correspondence between the visibility hierarchy and the key points provided by components and SO design. It also shows the interrelationship between them in the SOA and SOAD background. As for the representation, Unified Modeling Language, UML - Enhanced by some additional styling (STEREOTYPE) and summary - naturally become an important foundation for SOAD. Using Rational Unified Process (RUP, http://wwwarent/awdtools/rup/) - is considered to be one of the mainstream OOAD processes of iterative software development, Use the UML model with a primary value. However, RUP is based on OOAD principles, so it is not easy to maintain consistent with the SOA design. From the perspective of RUP, the system architecture is the architecture of its main components that have been defined interface interactions. In addition, these components are also composed of a smaller component that gradually decreases to a level of grade. Conversely, in SOA, the system architecture typically includes stateless, fully encapsulated and self-descriptive services that meet the required ordinary business services, which are closer to BPM, as shown in FIG. These services may include many collaborative or arranging services. This does not exclude the OO view used in RUP, but there is another abstraction layer. This super layer is to encapsulate components of the RUP component (software service) in a formal cross-layer interface structure. Soad Principle In this section, we will describe the needs of SOAD in more detail and begin to determine its subject and principle. The aim is to bring further design work on this topic. Further work undoubtedly requires a formal SOAD method.
What must SOAD must provide? The following requirements have been determined for SOAD: L is as any other item and method, must be officially (at least half formally) defined processes and representations. Additional principles can be determined when needed by selecting and combining OOAD, BPM, and EA principles. l Multi-Structured method is conceptualized: M OOAD provides us with classes and objects on the application layer, while BPM has a process-driven process model. SOAD needs to combine them together. The M method is no longer a-oriented, but is driven by business events and processes. The model model is carried out as the second step in a lower level. The M method includes grammar, semantics, and strategies. This requires special combination, semantic proxy and runtime discovery. l SOAD must provide a well-defined quality factor and best practice (such as answering granularity issues). The role question raised by BPEL must be answered. For example, who is some of the work is responsible: Is it a developer, architect, or analyst? l SOAD activity must also answer this question: What is not a good service? For example: anything that is uncomfortable is impossible to become a good first-class SOA member (ie service). Another example is an embedded real-time system with challenging non-functional requirements, which cannot withstand any XML processing overhead. l SOAD must be easy to perform end-to-end modeling, and have a comprehensive tool support. If SOA brings flexibility and agility to your business, you should have the same expectations on the support methods generated by the enterprise to architecture and application design. Some general principles or quality factors have been determined, and can be used as design reference references in SOAD, which has a flexibility and agility to the business; they are easier to reconstructive, encapsulation, and information hidden . l Designed a good service is meaningful, and not only for enterprise applications; the dependence between services is minimized and is explicitly declared. l Service Abstraction is a consolidation, complete and consistent; for example, you should consider Creat, Read (Read), Read, Read, Update, Delete (SEARCH) Metaphor. l The assumptions that are often declared are stateless (e.g., non-conversational); in order to request services in a particular problem domain and context, this declaration will be weakened. l The expertise of experts can understand the service name without the expertise of the domain. l In SOA, all services follow the same design system (by mode and template) and interactive mode; the underlying architecture can be easily identified (eg, during the architecture review period). l Service and Service Users have only necessary basic programming language skills outside the domain knowledge; only a few professional knowledge is needed, in the ideal case, this knowledge is used for tools and runtime manufacturers. Instead of making companies used in corporate applications like SOA.
Service ID and Define Self-descending business-level modeling techniques (such as CBM) can provide starting points for SOA modeling activities. However, as we mentioned earlier, SOA achieves very little is starting in a new project; creating a SOA solution requires almost always involving integrated existing legacy systems, and the method is to break down them into services, operation, business processes and Business Rules (see Figure 6 at the same time): l Decompose existing applications and vendor software packages into discrete service sets representing the relevant operational group (bottom-up method). l From the application to abstract the business processes and rules to manage separate BPMs managed by the service. All OOAD is related to the identity and definition service; however, it also needs to have a higher level. In addition, when SOA is committed to higher development than classical development project hierarchies, there is room for other creative thinking. Direct and indirect business analysis through project-related personnel talks and CBMs for BPM and direct demand analysis are a method of easy understanding and very suitable identification candidate services. The past experience shows that this main way should be improved by complementing indirect technology. The product manager and other business leaders should negotiate when selecting candidate services. For example, what is planning payment and billing model? It should be discussed to assume the organizational structure of the enterprise that is building the system being built. It is recommended to consider any existing business model in a non-SOA project. The term for marketing for the system in which the system being constructed is another good source of service candidates (especially verbs, very much attention to marketing verbs!).
Domain Decomposition in endrei (http://publib-b.boulder.ibm.com/redbooks.nsf/redbookabstract ", the domain decomposition, subsystem analysis, target model creation, and related technology defined in endml?open) is the SOA process Construction methods or service conceptualization framework (which is the most promising proposal based on the previously completed work previously completed. FODA (http://www.sei.cmu.edu/domain-engineering/foda.html) work is also contributed to this discussion in this area. The service granularity selection correct abstract level is a key issue in service modeling. You often hear suggestions for coarse granular modeling. This is a bit too simplistic. You should change it to coarse particle size modeling as much as possible without loss or harm correlation, consistency, and integrity. In any SOA, there are fine-grained service abstract spaces (if there is a business requirement). Since SOA is not equivalent to Web services and SOAP, you can use different protocol bindings to access different levels of services. Another option is to bring some associated service bundle into a coarse granular service definition, which is a variant of the facade pattern. Naming agreements should define Enterprise Naming Mode (XML namespace, Java package name, internet). A simple example is always named the service with a noun, and use the verb to name actions. This best practice is derived from OOAD space. In addition to combining OOAD, BPM, and EA technology, there are several important SOAD concepts and aspects to be enrichment: l Serving classification and aggregate l strategy and aspects l Agent service classification and aggregate services have different usage and use; for example, software services can be different from business services (as shown in Figure 5 above). In addition, the atomic service can be equipped with a higher level and fully functional service. Service portfolio can be simplified by executive models such as BPEL modeling; this is a traditional modeling tool and method that cannot be handled. Policies and aspects have grammar, semantics, and QoS features, all of which must be modeled; formal interface contracts must cover more than Web Services Description Language (WSDL). Therefore, the Web Service Policy Framework (WS-Policy, Http://www.ibm.com/ws-polfram/) is an important relevant specification. In addition to the principle of a good architecture that has been developed, business trackability is also an ideal quality: It is possible to link all runtime components directly to language that can be understood by non-technical field experts. This is very important for the abstraction disclosed directly in business and service. SARBANES-OXLEY (SOX) Act (see Articles from ASTOR), http: //sys-con.com/author/? ID = 526) is an example of a business driver that requires such business traceability. Process: In the real world, there is no new project that must always consider the legacy system (the legacy system is the synonym of existing systems). Therefore, there is a need to meet the method, not the simple auto-down or bottom-up process. Up to the existing IT environment instead of now and future business needs, the bottom-up method often leads to bad business services. The top-down method may produce short-term non-functional demand features, and harm other architectural quality factors (such as performance issues caused by deficiency in the domain model), in addition, in services and components Generate a bad problem that does not match.
Service Acquisition and Knowledge Agents This is a knowledge management and life cycle issue: How to successfully prepare the service and make it reuse after conceptualization? Reuse should be regarded as one of the most important promoters of the logo and definition service. If the component (or service) is impossible to reuse, it will not be deployed as a service. It can be connected to another service related to the enterprise architecture, but cannot be used as a service separately. However, even if you have a reuse from starting, you must also form a service acquisition process. The service use of multiple users is a clear SOA design goal. Building a service registration center (such as a business uddi directory) may be able to solve some problems.
Example: Automotive Work Order describes the process of car maintenance company to manage its customers. We will explain the view of SOAD through issues in this field. Work orders represent the agreement between car service companies and customers to conduct a series of routine maintenance or emergency repairs, such as Routine 50,000 miles, replace the brake pads or tires, or change oil. The business scene (shown in Figure 7) is as follows: l Create a working order when the customer calls an appointment. l Create an independent work order item for each program's maintenance activities or operation, including the parts, spare parts, and the details of the services you need to use. l Make sure all necessary parts have inventory before scheduled an appointment. l The maintenance between each working order item is required to have the appropriate equipment and a machine with appropriate conditions. l Computing the total cost of the estimate, then the customer is approved; or the plan is terminated, and the work order will be canceled. l Before an appointment, install the necessary parts, spare parts, tools, and devices in selected maintenance. l When the customer arrives, the planned activities and any other activities necessary when checking the means of transport. l Record the actual value of the parts and spare parts used and the service. l Computing the total cost when all repairs are completed. l Create an invoice and hand it over to the customer. If you start this as a separate application from the beginning, you may create a set of classes as shown in Figure 8. If you construct a work order as an OO application, these software objects will contain all required business rules and understand the business processes that should be followed. However, this method has some shortcomings in practice: l Many steps involve connections to existing legacy systems and databases (such as billing, schedule, and inventory systems), it is impossible to follow the OO paradigm (in this way In the case of applying the adapter or arbiter. l In order to make the system as flexible as possible, some rules can be helpful, so they can modify the flow or workflow without changing the code. For example, a rule below: L The standard 24,000 miles of services include four flour oil. Just use four liters of oil or customers to require high quality oil (such as synthetic oil), extra posts should be charged. l There is a set of industrial standards in legacy applications to conduct valuations for ordinary auto repair activities. Customers should pay the standard labor costs unless the cost of the maintenance person exceeds the value of the valuation exceeds the value of the valuation and the reason for the report. l If you exceed the Y% of the valuation, you should contact the customer for confirmation. SOAD provides excellent solutions for these issues. This group of services is slightly different from the service objects because it is grouped based on relevant behaviors rather than encapsulation (behavior and data). For example, you may be able to divide the Work Order and Work Order Items to Work Order Services, and create schedule (Catalog), catalog, and inventory service. . In addition, because there is no service example, there is no such thing as the relationship between services. The service model of the working order may appear as shown in Figure 9. Unlike the OO paradigm, this model does not represent a functional system. There is no consideration, and there is no business event or rule. In the SOA paradigm, business process arrangements maintained outside the service determine the order and time of the execution service call. Conceptually, from the first customer to complete the work and bill payment to represent a single macro hierarchy working unit, and have a life cycle of several days to several weeks. After all, from the perspective of the company, the work unit will generate income.
However, the actual situation is a series of centralized activities that occur in a relatively long period of time, such as defining activities, arrangements, selection parts, spare parts, and maintenance activities. In an IT system, there is no actual process last for a few minutes; the traffic flow between events is saved in the database in the form of data. This type of process can be made well in a state transition model (e.g., available in UML). Figure 10 shows an example of how to model business flow with a finite-state machine method. It is a high-level view of how to change the status of the working order when the business process is performed. Business processes These transformations are set in the state. Separate operations Permanently record the relevant state changes. Figure 11 shows an example of partial arrangement, including steps 1 through 5 (e.g., customer defining the work required by the service) shown in Figure 10, and scheduled an appointment for implementation. Summary and Prospects In this article, we have discussed and inspired the needs of innovative intervening methods, which sets the bridge between business and IT and supports the analysis and design phase of the SOA project. We also offer this new SOAD method of this new cross-discipline as an overall modeling rule, which is based on a good and widely praised OOAD, EA, and BPM. While defining the SOAD representation and procedures, key principles, such as service conceptualization (or identification), service classification, or aggregation, policies, and aspects, intermediate meeting processes, semantic proxy and service acquisition (for use). SOAD needs to enhance existing software development methods to further improve the availability and applicability of enterprise application development projects. Over time, development is also the best practice. We also realize that UML will continue to dominate the representation of the representation of the process; it may be necessary to enhance the requirements to meet the more wide SOAD. Completing the next step in the SOAD method is to define the required end-to-end processes and representations, review activities and their responsibilities, and continue to check the validity of the proposed approach in the project.
