News Contents

Toplam 29 İlan Bulundu

Backend-For-Frontend using GraphQL under Microservices

Microservices are an architectural style, in which the analysis and modeling of specific business areas, complex applications are decomposed into a group of services that are small and specific, have a low degree of coupling. Each microservice is a small, independent and deployable application.

This concept of microservice architecture is similar to the concept of separating the frontend and backend. The frontend application controls all of its own UI-level logic, while the business logic is accomplished through API calls to the relevant microservice. After the continuous growth of frontend single page application frameworks, and the spread of mobile apps, whether it is a Mobile Native development or a Hybrid application development, so frontend and backend separation has made Web and Mobile applications become clients. The client only needs to query and modify the resources through the API.

The following figures shows the main difference between the absence of BFF and the addition of BFF on the front and back ends.

1. Traditional frontend and backend separation application

 

In the traditional frontend and backend design, usually the Mobile App or Website directly accesses the backend service, the backend microservices call each other, and then return the final result to the frontend client. For clients (especially mobile), too many HTTP requests are expensive. Therefore, in order to minimize the number of requests, the frontend generally tends to obtain associated data through a single API. It means that sometimes the backend will do some UI-related logic processing to meet the needs of the client .

2. BFF’s frontend and backend architecture

 

The biggest difference in BFF’s frontend and backend architectures is that the frontend (Mobile, Web) no longer directly accesses the backend microservices, but rather accesses it through the BFF layer. And each client will have a BFF service. With BFF, there are fewer mutual calls between microservices. This is because some UI logic is processed at the BFF level.

BFF and API Gateway

From the above understanding of BFF, since BFF is a middle-tier service accessed by frontend and backend, what is the difference between BFF and API Gateway? Let’s first look at the common implementation of API Gateway. (The API Gateway may be designed in many ways. Here are just three examples.)

1. API Gateway provides the same API for all clients

For example: /api/accounts. In this case, API Gateway does not distinguish between client types, as shown below:

 

2. API Gateway provides separate APIs for each client

For example: /services/mobile/api/accounts and /services/web/api/accounts. The API Gateway determines which client it comes from, based on different APIs, and then processes them separately to return the resources required by different clients.

 

3. Multiple API Gateways provide separate APIs for each client

BFF is actually considered like this implementation mode of API Gateway.

 

GraphQL and REST

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

What are the similarities and differences between GraphQL and REST? We can understand it by the following example:

REST can be accessed through the following way:

Request:

GET http://127.0.0.1/api/accounts

Response:

[
{
"id": 88,
"name": "Mena Meseha",
"photo": "
http://bucket.s3.amazonaws.com/photo.jpg"
},
...
]

For the same request if accessed with GraphQL, the process is as follows:

Request:

POST http://127.0.0.1/graphql

Body:

query {accounts { id, name, photo } }

Response:

{
"data": {
"accounts": [
{
"id": 88,
"name": "Mena Meseha",
"photo": "
http://bucket.s3.amazonaws.com/photo.jpg"
},
...
]
}
}

Compared to the REST style, GraphQL has the following features:

1. On demand data model definition

For example, for the above /accounts access, if the client is only interested in account.id and account.name. So client only need to pass account {id
name}
to query. The model is defined in the background. The client only needs to obtain the data it cares about.

2. Get many resources in a single request

For example, you may need to obtain account.friends and account.friends.address, In fact, this query need to get the data from 3 different resources which are accountfriends and address. In REST mode, the account data may needs to be sent again to another API to get the friends and address info. GraphQL can query for nested levels of data so it greatly reduces the number of client requests and allows the client to obtain all the required data through a single API as the following query:

{
account(id:88) { // 1st Level
name,
friends { // 2nd Level
name,
address { // 3rd Level
country,
city
}
}
}
}

GraphQL vs REST

For the comparison between GraphQL and REST, there are mainly the following differences:

1. Data Acquisition: REST lacks scalability and GraphQL can be accessed on demand. The payload can be extended when the GraphQL API is called.

2. API calls: REST’s operation for each resource is an endpoint, and GraphQL only needs a single endpoint, but the post body is not the same.

3. Complex data requests: REST requires multiple calls for nested complex data, GraphQL calls once, reducing network overhead.

4. Error code processing: REST can accurately return HTTP error code, GraphQL returns 200 uniformly, and wraps error information.

5. Version number: REST is implemented via v1/v2, and GraphQL is implemented through the Schema extension.

Microservices + GraphQL + BFF Practice

I recommend to use express-graphql to build the BFF side of the project and then deploy it through Docker, and between the BFF and the microservices backend, there is service registration and discovery are performed through Consul.

 
Sample Technical Architecture for Microservices + GraphQL + BFF
 
BFF Technology Stack

Authentication and Authorization

Authentication and authorization are other issue that need to be considered when using GraphQL. Do we process them before or after the GraphQL parsing process?

To answer this question, you can think of GraphQL as a DSL (Domain Specific Language) on top of your own backend data acquisition logic. We just need to think of it as an intermediate layer that can be placed between the client and our actual data service (or multiple services).

Then consider authentication and authorization as another layer. GraphQL is not useful in the actual implementation of authentication or authorization logic because it does not mean it. However, if we want to place these layers behind GraphQL, we can use GraphQL to pass the access token between the client and Auth API. This is very similar to the way we authenticate and authorize via the RESTful API.

3. GraphQL + BFF Practices

Through the following aspects, you can think about some of the better qualities of GraphQL-based BFF:

GraphQL and BFF’s focus on business points

 

From a business point of view, the property manager (PM App) is concerned with property, because the property manager manages a group of houses, so it is necessary to know all the house profiles, and for each house need to know whether there is a corresponding maintenance application. Therefore, PM App BFF data structure is defined, maintemamceRequests is property sub-attribute.

With similar data, the house maintenance supplier (Supplier App) is concerned with maintenance request (maintenance work order), so in the data obtained by the Supplier App, our main body is maintenanceRequest.

So because there are different usage scenarios, different clients have different concerns for the same data. From this perspective, the data structure defined in the BFF is what the client really cares about. BFF is born for the client and is part of the client. It should be noted that the "business focus" does not mean that the BFF will handle all the business logic. The business logic should still be taken care of by the micro service. The BFF is concerned with what the client needs.

GraphQL support for versioning

 
Figure (1) -> Figure (2) -> Figure (3)

Assume BFF end has been released into the production environment. Now we need to change the structure of Figure (1) to the structure of Figure (2), but in order not to affect the API access of the old users, our BFF API must be compatible at this time. If REST, we may update the API version. But in BFF, we can use the structure of Figure (3) for forward compatibility. At this time, the old APP uses the data structure of the yellow area, while the new APP uses the structure defined by the blue area.

Conclusion

Building a BFF based on GraphQL under microservices is not a silver bullet. It is not necessarily suitable for all projects. For example, after you use GraphQL, you may have to face multiple query performance issues, but this does not prevent it from becoming a good attempt. You do see that Facebook has already used GraphQL, and that Github has also opened GraphQL’s API. This article only serves as an introduction to the idea. I hope that there will be more sharing about the use of BFF in the community.

Show More Devamı
Tüm Yorumlar - All Comments

In web development, such terms as ””web app””, ””front-end architecture””, ””Web 2.0””, and ””HTML5 apps”” are often used in a misleading context which doesn”t consider the full specifics of implementation and usage of web architectures. Today we”ll find out more about the web application architecture types in the light of the latest web trends and key issues that matter to software product owners.

 

We can outline 3 main web application architecture types and discuss their advantages and drawbacks. We can evaluate them according to three points of view: software owner, software developer (member of the dedicated team allocated to the project) and end user. Other possible examples basically come down to these three as subtypes.

 

First let”s define a web application: it”s a client-server application, where there”s a browser (the client) and a web server. The logic of a web application is distributed among the server and the client, there”s a channel for information exchange, and the data is stored mainly on the server. Further details depend on the architecture: different ones place and distribute the logic in different ways.

 

It”s hard to compare completely different architectures impartially. But we”ll try to, using several evaluation criteria.

 

User”s criteria

 


Responsiveness/Usability
Updates of data on pages, switching between pages (response time). Such qualities of user interface as richness and intuitivity.

Linkability
Ability to save bookmarks and links to various sections of the website.

Offline work
Well, this one speaks for itself.

 

Developer”s criteria

 

Speed of development
Introduction of new features, refactoring, parallelization of the software development process.

Performance
Maximum speed of response from the server with minimum consumption of computation power.

Scalability
Ability to increase computation power or disc space under increases in amounts of information and/or number of users. If an allocated scalable system is used, one must provide data consistency, availability and partition tolerance (CAP theorem). It”s also worth noting that the case, when the number of features/screens of the client app is increased at the software owner”s request, depends on the framework and implementation rather than the type of web application architecture.

Testability
Possibility and ease of automated unit testing.

 

Software product owner”s criteria

 

Functional extendability
New functionality within minimal time and budget.

SEO
Users must be able to find the application through any search engine.

Support
Besides software development proper, there are additional expenses: hardware, network infrastructure, maintenance.

Security
The software owner must be sure that both business data and information about users are kept secure. As the main security criterion we”ll consider the possibility of changes in functionality of app behavior on the client side, and all associated risks. Standard dangers are the same for the compared architectures. We do not consider security on the server-client channel, because all these architectures are equally exposed to break-ins. This channel can be the same.

Conversion: website – mobile or desktop application
Conversion into a mobile or desktop application with minimal additional costs. 

 

Some of these criteria might seem inaccurate, but the purpose of the article is not to show what”s good and what”s bad. It”s more of a detailed review that shows the possible options.

 

Let”s outline three main web-based application types according to the roles performed by the server and the client browser.

 

 

Type 1: server-side HTML web application

 

web app

 

The most widespread web application architecture. The server generates HTML content and sends it to the client as a full-fledged HTML-page. Sometimes this architecture is called ””Web 1.0””, since it was the first to appear and currently dominates the sphere of web development.

 

  • Responsiveness/Usability: 1/5. The least optimal value among these architecture examples. A huge amount of data is transferred between the server and the client. The user has to wait until the whole page reloads, responding to trivial actions, for example, when only a part of the page needs to be reloaded. UI templates on the client depend directly on the frameworks applied on the server. Due to the limitations of mobile internet and huge amounts of transferred data, this architecture is hardly applicable in the mobile segment. There are no means of sending instant data updates or changes in real time. If we consider the possibility of real-time updates via generation of ready chunks of content on the server side and updates of the client (through AJAX, WebSockets), plus design with partial changes within a page, we”ll go beyond this architecture.

 
  • Linkability: 5/5. The highest of the three, since it”s the easiest implementable. It”s due to the fact that by default one URL receives particular HTML-content on the server.

 
  • SEO: 5/5. Rather easily implemented, similarly to the previous criterion. The content is known beforehand.

 
  • Speed of development: 5/5. This is the oldest architecture in web development, so it”s possible to choose any server language and framework for particular needs.

 
  • Scalability: 4/5. If we take a look at the generation of HTML, under the increasing load comes the moment when load balance will be needed. There”s a much more complicated situation with scaling databases, but this task is the same for these three examples of software architecture.

 
  • Performance: 3/5. Tightly bound to responsiveness and scalability. Performance is relatively low because a big amount of data must be transferred, containing HTML, design, and business data. Therefore it”s necessary to generate data for the whole page (not only for the changed business data), and all the accompanying information (such as design).

 
  • Testability: 4/5. The good thing is that there”s no need for special tools, which support JavaScript interpretation, to test the front-end, and the content is static.

 
  • Security: 4/5. The application behavior logic is on the server side. However, data are transferred overtly, so a protected channel may be needed (which is basically a story of any architecture that concerns the server). All the security functionality is on the server side.

 
  • Conversion: website – mobile or desktop application: 0/5. In most cases it”s simply impossible. Rarely there”s an exception (more of exotics): for example, if the server is realized upon node.js, and there are no large databases; or if one utilizes third-party web services for data acquisition (however, it”s a more sophisticated variant of architecture). Thus one can wrap the application in node-webkit or analogous means.

 
  • Offline work: 2/5. Implemented with a manifest on the server, which is entered to HTML5 specifications. If the browser supports such a specification, all pages of the application will be cached: in case the connection is off, the user will see a cached page.

 

 

Type 2: JS generation widgets (AJAX)

 

web application

 

This is an evolved architecture of the first type. The difference is that the page, which is displayed in the browser, consists of widgets (functionally independent units). Data is uploaded to these widgets through AJAX query from the server: either as a full-fledged chunk of HTML, or as JSON, and transforms (through JavaScript templating/binding) into the content of the page. The option of uploading chunks of HTML excludes the necessity of using JavaScript-MV* frameworks on the client side; in this case something simpler can be used (for example, jQuery). By lowering interactivity we boost the development speed and make functionality cheaper and more reliable.

 

The foremost advantage is that updates from the server arrive only for the part of the page requested by the client. It”s also good that widgets are separated functionally. A particular widget is in charge of a part of the page; partial changes will not affect the whole page.

 

  • Responsiveness/Usability: 3/5. The volume of transferred data for a part of a page is smaller than for the whole page, that”s why responsiveness is higher. But since a page is a set of widgets, the applicable UI templates in a web application are limited by the chosen UI framework. Cold start (the first full loading) of such a page will take a little longer. The content, which is fully generated and cached on the server, can be instantly displayed on the client; here time is spent on getting the data for the widget and, as a rule, on templating. At the first visit the website will not be that quick to load, but further it will be much more pleasant in use, if compared to sites based on the architecture of the first type. Also it”s worth to mention the possibility of implementation of ””partial”” loading (like it”s done on yahoo.com).

 
  • Linkability: 2/5. Here special tools and mechanisms are needed. As a rule, Hash-Bang mechanism is applied.

 
  • SEO: 2/5. There are special mechanisms for these tasks. For example, for promotion of websites based on this architecture it”s possible to predefine the list of promoted pages and make static URLs for them, without parameters and modifiers.

 
  • Speed of development: 3/5. One needs to know the server-side technologies in web development, and use JavaScript frameworks on the client side. It”s also required to implement web services on the server side.

 
  • Performance: 4/5. The time and resources spent on generation of HTML content are relatively minor if compared to the time spent by the app on retrieving data from the databases, and on their processing before templating. Use of the extended type of this architecture (when data are transferred as JSON) lowers the traffic between the client and the server, but adds an abstraction level to the application: retrieval from database -> data processing, serialization in JSON -> API: JSON -> parsing of JSON -> binding of data object on the client to HTML.

 
  • Scalability: 4/5. Same as for the first type of architecture.

 
  • Testability: 1/5. It”s required to test the server side, the client code, and the web service which returns the data to update widgets.

 
  • Security: 4/5. Part of the logic is shifted to the client JavaScript which can be modified by an intruder.

 
  • Conversion: website – mobile or desktop application: 0/5. Same as for the first type of architecture.

 
  • Offline work: 1/5. The manifest mechanism works in this case, but there”s a problem with updating or caching the data displayed on the widget. This functionality has to be implemented additionally: in the manifest one can indicate only names of the files that will be cached from the server. Correlation between the widget template file, cached in the manifest, and the page behavior logic requires extra effort.

 

 

Type 3: service-oriented single-page web apps (Web 2.0, HTML5 apps)

 

web application

 

The term ””Web 2.0”” isn”t quite correct here. One of peculiarities of Web 2.0 is the principle of involving users into filling and repeated adjustments of content. Basically the term ””Web 2.0”” means projects and services which are actively developed and improved by users themselves: blogs, wikis, social networks. This means Web 2.0 isn”t bound to one technology or a set of technologies.

 

Let”s figure out the essence of this architecture. An HTML-page is downloaded from the server. This page is a container for JavaScript code, which addresses a particular web service and retrieves business data only. The data is used by JavaScript application, which generates the HTML content of the page. This architecture is a self-sufficient and rather complex JavaScript application, where part of the functionality is shifted to the client side. To compare, the architecture of the second type cannot show a high number of interrelated and structured functions.

 

In modern web development, fully offline JavaScript apps are rare (with a few exceptions, e.g. rad-js.com). This approach allows an easily made reverse conversion: publish an existing application on the web.

 

  • Responsiveness/Usability: 5/5. The volume of data transferred for updates, is minimal. That”s why responsiveness is at the highest level. UI is generated via JavaScript, it”s possible to implement any necessary variants. There is an issue with multithreading in JavaScript: in this particular case processing of big volumes of business data should be shifted to the web service.

 
  • Linkability: 1/5. One will need special tools and mechanisms, as well as frameworks which can use, for example, Hash-Bang mechanism.

 
  • SEO: 1/5. The hardest one to promote. If the entire app is promoted directly, there”s no problem: it”s possible to promote the application container. If it”s needed for a part of the application, a special mechanism will be needed for that purpose. Each more or less big search engine offers its own methods of standartization for this process.

 
  • Speed of development: 2/5. It”s required to develop a web service and apply more specialized JavaScript frameworks which build the app architecture. Since the architecture is relatively new, there aren”t many specialists who are able to create a high-quality site/system based on this approach. There aren”t many time-tested tools, frameworks and approaches.

 
  • Performance: 5/5. This criterion is the least influenced on by the server side. The server only has to give the JavaScript application to the browser. On the client side, performance and browser type are of the biggest importance.

 
  • Scalability: 5/5. The web logic is on the client side. There is no content generation on the server. When there”s an increase in the number of users, it”s required to scale only the web services that give the business data.

 
  • Testability: 3/5. It”s required to test web services and the client JavaScript code.

 
  • Security: 0/5. The logic is shifted to the client JavaScript, which can be relatively easily modified by an intruder. For protected systems it”s required to develop a preventive architecture, which considers the peculiarities of open-source applications.

 
  • Conversion: website – mobile or desktop application: 5/5. A website becomes an application with the help of PhoneGap or a similar platform.

 
  • Offline work: 5/5. This architecture is a full-fledged application; it”s possible to save separate data, as well as parts of the application using any storage (for example, local storage). One more advantage is the possibility to switch data storage and management to the offline mode. To compare, the two aforementioned architectures are only partially functional in the offline mode. Here the missing data can be replaced with mocks, it”s possible to show alert windows or use data from the local storage, while synchronization may be left for later.

 

Thus we can see that there”s no perfect architecture. The optimal choice depends on tasks and priorities. If any criterion wasn”t mentioned here, it doesn”t mean it was ignored. It”s just the fact that for each particular software project every criterion has different importance. For every real software development project one of these examples may be defining. It”s also possible to optimize the architecture of the app or implement a hybrid architecture which will meet the specific business requirements.

Show More Devamı
Tüm Yorumlar - All Comments

Nesneye yönelik analiz - HW1_LinearSolverDeluxe

 

Gaussian Elimination Method Matrix Inversion Method
package com.aydincalikoglu.LinearSolverDeluxeService.impl;

import com.aydincalikoglu.LinearSolverDeluxeService.Solver;

import java.util.*;
import java.util.List;
import java.util.stream.Collectors;

import static java.lang.Math.abs;

/**
* Created by Aydın on 11.10.2018.
*/
public class GaussianElimination implements Solver {
private List<List<Double>> katSayilar;
private List<Double> sabitler;
private List<Double> x = new ArrayList<Double>();

/**
* Kat sayılar ile aldığı sabitleri Gaus Elimination yöntemi ile hesaplar ve sonuçları verir.
* @param katSayilar
* @param sabitler
* @return ArrayList olarak X değerlerini döndürür.
*/
private List<Double> calculate(List<List<Double>> katSayilar, List<Double> sabitler)
{
this.katSayilar=katSayilar;
this.sabitler = sabitler;
pivotlama(0,0);
if (!controlDiagonal(0)) {
System.out.println(“it couldnt calculate because there is 0 in diagonal of the matrix after GausElimanation“);
return null;
}
else
{
BackSubstitution();

}
return x;
}

/**
* Hesaplanmış olan üst üçgensel matrisi üzerinde, en alt x değerlerinden başlayarak tüm x değerlerini hesaplar.
*/
private void BackSubstitution()
{
int j=sabitler.size()-2;
for (int i = sabitler.size()-1; i >-1 ; i--) {
double sonuc=sabitler.get(i);
int l=0;
for (int k = sabitler.size()-1; k >j ; k--) {
if (l<x.size()) {
sonuc-=katSayilar.get(i).get(k)*x.get(l);
l++;
}
else
x.add(sonuc/katSayilar.get(i).get(k));
}
j--;
}
reverseListX();
}

/**
* Recursive Köşegen Matris kontrolü
* @param index
* @return Köşeğen matris ise true değerini verir.
*/
private boolean controlDiagonal(int index)
{
if (index==sabitler.size()) {
return true;
}
if (katSayilar.size()<index)
return false;
// Köşegen Matris kontrolü
if (katSayilar.get(index).get(index)==0) {
return false;
}
return controlDiagonal(index+1);
}

/**
* Maksimum pivotları tekrar hesaplamamak için dinamik bir yapı kullanılmıştır.
*/
private ArrayList<Double> maxPivot = new ArrayList<>();

/**
* Büyük Sayıların olduğu pivotları matris üzerinde en üste taşıyarak, Bölmelerde minumum hata payı elderek
* Her Satirda Gauss elimination yöntemini kullanılmıştır.
* @param col
* @param row
*/
private void pivotlama(int col,int row)
{
// Büyük Sayıların olduğu pivotları en üste taşıyarak, Bölmelerde minumum hata payı elde etmeye çalışıyoruz.
if (row==sabitler.size()-1) {
return;
}
double rowMaxNum=0;
int maxValueRowIndex=0;
for (int i = row; i < katSayilar.size(); i++) {
double colMaxNum=abs(katSayilar.get(i).get(col));
for (int j = col+1; j < katSayilar.get(i).size(); j++) {
double ColumnValue=abs(katSayilar.get(i).get(j));
if (colMaxNum<ColumnValue)
{
colMaxNum=ColumnValue;
}
}
if (row!=0) {
colMaxNum = maxPivot.get(i);
}
else
maxPivot.add(colMaxNum);

colMaxNum=abs(katSayilar.get(i).get(col))/colMaxNum;
if (rowMaxNum<colMaxNum) {
rowMaxNum=colMaxNum;
maxValueRowIndex=i;
}
}

// Kat sayılarda ve sabitlerde yer değiştirme
if (katSayilar.get(maxValueRowIndex).get(col)!=0) {
List<Double> tempAr=katSayilar.get(row);
katSayilar.set(row, katSayilar.get(maxValueRowIndex));
katSayilar.set(maxValueRowIndex, tempAr);
double tempSon=sabitler.get(row);
sabitler.set(row, sabitler.get(maxValueRowIndex));
sabitler.set(maxValueRowIndex, tempSon);
}
gaussElimination(col,row);
pivotlama(col+1,row+1);
}

/**
* Matris içerisinde verilen satır ve sütun sonrasındaki tüm satırları pivot elemanlarına bölerek üst üçgensel bir matrise yakınlaştırır.
* @param col
* @param row
*/
private void gaussElimination(int col,int row)
{
for (int i = row+1; i < katSayilar.size(); i++) {
if(katSayilar.get(i).get(row)==0)
continue;
double kat=katSayilar.get(i).get(row)/katSayilar.get(row).get(row);
for (int j = col; j < katSayilar.get(i).size(); j++) {
katSayilar.get(i).set(j, katSayilar.get(i).get(j)-(katSayilar.get(row).get(j)*kat));
}
sabitler.set(i,sabitler.get(i)-sabitler.get(row)*kat);
}
}

/**
* Kat sayılar matrisi ve sabitler matrisini ekrana yazdırır.
*/
public void printMatries()
{
for (int i = 0; i < katSayilar.size(); i++) {
for (int j = 0; j < katSayilar.get(i).size(); j++) {
System.out.printf(“%.4f “,katSayilar.get(i).get(j));
}
System.out.printf(“= %.4f
“,sabitler.get(i));
}
System.out.println();
}

@Override
public String toString() {
return x.stream().map(i -> System.out.format(“%.2f“,i).toString()).collect(Collectors.joining(System.lineSeparator()));
}

/**
* Hesaplanmış olan X değerlerini ekrana yazdırır.
*/
public void printAllX()
{
for (int i = 0; i < x.size(); i++) {
System.out.printf(“x%d: %.4f “,i+1,x.get(i));
}
System.out.println();
}

/**
* x değerlerini doğru sırayla listeye eklenmesi için reverse alınır.
*/
private void reverseListX()
{
if (x.size()==0)
return;
double temp=x.get(0);
x.remove(0);
reverseListX();
x.add(temp);
}

@Override
public List<Double> solveMatris(List<List<Double>> katSayilar, List<Double> sabitler) {
return calculate(katSayilar,sabitler);
}
}
package com.aydincalikoglu.LinearSolverDeluxeService.impl;

import com.aydincalikoglu.LinearSolverDeluxeService.Solver;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.stream.DoubleStream;

import static java.lang.Math.abs;

public class InverseMatrixMethod implements Solver {
@Override
public List<Double> solveMatris(List<List<Double>> katSayilar, List<Double> sabitler) {
return calculate(katSayilar, sabitler);
}

private List<Double> calculate(final List<List<Double>> katSayilar, List<Double> sabitler)
{
List<List<Double>> a = katSayilar;
List<Double> b = sabitler;

List<List<Double>> inverseA = inverse(a);
List<Double> result = multiply(inverse(a), b);

System.out.println(“The inverse is: “);
for (int i=0; i<inverseA.size(); ++i)
{
for (int j=0; j<inverseA.size(); ++j)
{
System.out.print(inverseA.get(i).get(j) +“ “);
}
System.out.println();
}

return result;
}

private double determinant(List<List<Double>> matris) {
if (matris.size() == 2)
return matris.get(0).get(0) * matris.get(1).get(1) - matris.get(0).get(1) * matris.get(1).get(0);

double det = 0;
for (int i = 0; i < matris.get(0).size(); i++) {
det += Math.pow(-1, i) * matris.get(0).get(i)
* determinant(minor(matris, 0, i));
}
return det;
}

public List<List<Double>> inverse(List<List<Double>> matris) {
List<List<Double>> inverseMatrix = new ArrayList<>();
// Minor ve kofaktor hesaplama
for (int i = 0; i < matris.size(); i++) {
inverseMatrix.add(new ArrayList<>());
for (int j = 0; j < matris.get(i).size(); j++) {
inverseMatrix.get(i).add(Math.pow(-1, i + j) * determinant(
minor(matris, i, j)));
}
}
double det = 1.0 / determinant(matris);
for (int i = 0; i < inverseMatrix.size(); i++) {
for (int j = 0; j <= i; j++) {
double temp = inverseMatrix.get(i).get(j);
inverseMatrix.get(i).set(j, inverseMatrix.get(j).get(i) * det);
inverseMatrix.get(j).set(i, temp * det);
}
}
return inverseMatrix;
}

private List<List<Double>> minor(List<List<Double>> matris, int row, int col) {
Double[][] minor = new Double[matris.size() - 1][matris.size() - 1];
for (int i = 0; i < matris.size(); i++)
for (int j = 0; i != row && j < matris.get(i).size(); j++)
if (j != col)
minor[i < row ? i : i - 1][j < col ? j : j - 1] = matris.get(i).get(j);
List<List<Double>> result = new ArrayList<>();
for(Double[] array : minor){
List<Double> list = Arrays.asList(Arrays.stream(array).toArray( Double[]::new ));
result.add(list);
}
return result;
}

private List<Double> multiply(List<List<Double>> a, List<Double> b) {
List<Double> result = new ArrayList<>();
for (int i = 0; i < a.size(); i++) {
double sum = 0;
for (int k = 0; k < a.get(i).size(); k++)
sum += a.get(i).get(k) * b.get(k);
result.add(sum);
}
return result;
}
}

Show More Devamı
Tüm Yorumlar - All Comments

SOFTWARE REQUIREMENTS
SPECIFICATION
for
PLAN and CODE
Prepared by Group 1
CSE343 - Software Engineering
Gebze Technical University
November 15, 2017

1 Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of the Plan and Code
which is part of web-based open-source DevOps software.It will explain the purpose and
features of the Plan and Code or rather Trello and Git tools that will be used.Additionally
the interfaces of the Plan and Code part and what can be done in Plan and Code part
and the constraints under which it must operate. This document is intended for users
of the software and also potential developers.
1.2 Document Conventions
This Document was created based on the IEEE template for System Requirement Spec-
i cation Documents.
1.3 Intended Audience and Reading Suggestions
 Typical Users, such as students, who want to use DevOps e.g. (for managing their
group projects)
 Advanced/Professional Users, such as engineers or researchers, who want to use
DevOps portal for more demanding their projects plans.
 Programmers who are interested in working on the project by further developing
it or x existing bugs.
1.4 Product Scope
Plan and code" part of DevOps portal is a tool that allows developers to plan their
work better and they can use it to synchronize their code very easily.Developers can
add new projects and represent their jobs with using cards.Every cards represents a new
assigned job for developer.In this way, Developers determines jobs done easily.
This is a software part a "DevOpslife cycle"
4
1.5 References
Trello”s website: https://trello.com/
Github”s website: https://github.com/
5
2 Overall Description
2.1 Product Perspective
Plan and code" part of the Dev-Ops portal is designed to handle projects and works in
it automatically via Trello Api. Project manager can start-up new projects and works
in it, developers can choose between these works and sent it to test when they nished
working on it.
Planning part”s main functionality is that all the project members can see process
of the project via Trello but all the required changes in Trello, can be made from our
portal. So this leads the project management to be more compact.
On the other hand, coding part of Dev-Ops portal will handle synchronization between
GitHub and Trello very eciently. Project members can see easily where their code right
now.
2.2 Product Functions
Project:
1. New Project: Creation of new project
2. Show Projects: Displaying existing projects in Trello
3. Choose Project: Deciding which project will be current project
4. Current Project: Displaying current project in Trello
Works:
1. Add Work: Creating new work in current project
2. Show Works: Displaying existing works in Trello
3. Choose Work: Deciding which work will be tested
4. Current Work: Displaying current card in Trello
5. Show Work: Choosing this work as new job
6. Delete Work: Removing work from works list
6
Members:
1. Add Member: Authorize a new member in current project
Code:
1. Close branch: Sending current work to test
Git:
1. Get Current Project Link : Getting current project link for built team
2.3 User Classes and Characteristics
 Typical Users, such as students, who want to be organized while developing pro-
grams not big projects.
 Big Companies, which want to handle more than one projects at once. Developer
team and project managers can work together easily with this software.
2.4 Operating Environment
 Web
 LocalHost
2.5 Design and Implementation Constraints
In the planning section, there are 5 lists by default including ToDo, Doing, Built, Test
and Deploy. So the manager can not set the number of lists and name of lists.
Each work has to pass successfully from all the lists until it is deployed. For example,
a non-built work can not be tested.
The manager can not manually switch works from one list to another.
2.6 User Documentation
Administrators create a project via Trello and authorize speci c members for this project.
Members plan to do the work after the plan will be recorded in the section. A member
of the Coding team chooses one of the tasks to be done and indicates that he is working
on it, and the job goes to the doing section. After completing its work through github,
it says that it has delivered the built. Built members is delivered to the test members
if successful. test members is delivered to the deploy members if successful. Therefore,
the application will run after you complete certain steps on trello.
7
2.7 Assumptions and Dependencies
DevOps communicates via the trello and github tools, and there are some restrictions
on the use of these tools via the DevOps portals. The trello tool can only be used online
because the trello tool does not have Local Server support.
8
3 External Interface Requirements
3.1 User Interfaces
Figure 3.1
9
3.2 Hardware Interfaces
Figure 3.2
3.3 Software Interfaces
Figure 3.3.
10
4 System Features
4.1 Cards
Everything you need to organize projects of any size. Open a card and you can add
comments, upload le attachments, create checklists, add labels and due dates, and
more.
4.1.1 Description and Priority
Open a card to keep information such as attachments, checklists and due dates. Priority:
High
4.1.2 Stimulus/Response Sequences
Users can open and close cards,in case they are managers, they can assign cards to
others.
4.1.3 Functional Requirements
REQ-1:Cards will not appear on the list when they are closed.Closed cards are considered
successful. REQ-2:Users are responsible for bad-input
4.2 User Management
What project managers do with users which are registered to the project
4.2.1 Description and Priority
Managing user in a project. Priority: High.
4.2.2 Stimulus/Response Sequences
Project Managers can add and remove anyone to the project and keep track of changes.
4.2.3 Functional Requirements
REQ-1: Those who are not registered to the system cannot be added to the project.
REQ-2: Users can use other tools when they are added. REQ-3: User information will
be stored in a database and will be compared when they log in.
11
4.3 Boards
A list is a collection of cards. They may represent a collection of ideas, things to
remember, or di erent stages of a work
ow.
4.3.1 Stimulus/Response Sequences
Users can create boards from cards they can also edit and remove them.
4.3.2 Functional Requirements
REQ-1:Boards must have cards. REQ-2:Empty boards must not be shown.
12
5 Other Nonfunctional Requirements
5.1 Performance Requirements
Plan and Code" is dependent on GitHub and Trello performances.
The board performance for boards which has lots of cards (>1000) the board might
not perform as well. Because Trello has to load open cards and attachments every time
a board is opened, boards with a large number of open cards may see slower load times
and generally reduced usability. We suggest having fewer than 1,000 open cards on any
Trello board (and under 500 if there are a lot of attachments or checklists on the cards).
5.2 Safety Requirements
"Plan and Code" is dependent on GitHub and Trello safeties.
GitHub provides dedicated rewall and VPN services to help block unauthorized sys-
tem access and also provides Distributed Denial of Service (DDoS) mitigation services.
5.3 Security Requirements
GitHub provides dedicated rewall and VPN services to help block unauthorized system
access and also provides Distributed Denial of Service (DDoS) mitigation services.
The Safe Harbor (http://export.gov/safeharbor/) framework used as a guideline for
good security practice for Trello. The Trello speci c security policy can be found here
https://trello.com/privacy.
5.4 Software Quality Attributes
Plan and Code" provides to use planning and coding together with interactive way on
DevOps Portal from both experts and typical users. However, users must already have
a basic knowledge of Trello and GitHub before using it.
13
6 Other Requirements
6.1 Appendix A: Glossary
1. Project: Every project is represented as Board in Trello. When a project is created,
new Board is created in Trello.
2. Work: Every work is represented as Card in Trello. When a work is created, a
new Card is created in current board”s To Do" list in Trello. Card”s location in
board will change in time. Ex. if test is successful for any card, this card will be
carried to Done" list. When user chooses to start work on chosen work. Card
will be carried to Doing" list.
3. List: As mentioned above, Projects are represented as Boards in Trello.When a
project is created, there will be 6 default lists in this board as: To Do" Doing"
Build" Test" Deploy" Done"
4. Branch: Every work is represented as Branch in GitHub. When close branch is
pressed, code will be sent to test.

Show More Devamı
Tüm Yorumlar - All Comments