Spaces:
Sleeping
Sleeping
ultima mensagem
Browse files- __pycache__/app.cpython-310.pyc +0 -0
- app.py +21 -15
- dataset/ALOY_deep-se.csv +1 -1
- gerar_modelos/gerar_modelos_mbr.py +22 -0
- gerar_modelos/gerar_modelos_neosp.py +45 -0
- gerar_modelos/gerar_modelos_tfidfsvm.py +36 -0
- gerar_modelos/temp.py +13 -0
- model/model_tawos_aloy_mbr.pkl +1 -1
- model/model_tawos_aloy_neosp.pkl +2 -2
- model/{model_tawos_aloy_tfidf_svm.pkl → model_tawos_aloy_tfidfsvm.pkl} +2 -2
- model/vectorizer_tfidf.pkl +3 -0
__pycache__/app.cpython-310.pyc
CHANGED
Binary files a/__pycache__/app.cpython-310.pyc and b/__pycache__/app.cpython-310.pyc differ
|
|
app.py
CHANGED
@@ -10,14 +10,20 @@ import pandas as pd
|
|
10 |
from textblob import TextBlob
|
11 |
import textstat
|
12 |
|
13 |
-
|
14 |
-
|
15 |
|
16 |
-
|
17 |
-
|
18 |
|
19 |
-
|
20 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
21 |
|
22 |
def calcula_MbR(titulo, descricao):
|
23 |
context = titulo + descricao
|
@@ -56,27 +62,27 @@ def calcula_neosp(titulo, descricao):
|
|
56 |
return story_points
|
57 |
|
58 |
def calculaTFIDFSVM(titulo, descricao):
|
59 |
-
model = load("model/
|
60 |
context = titulo + descricao
|
61 |
d = {"context": [context]}
|
62 |
df = pd.DataFrame(data=d, columns=["context"])
|
63 |
-
vectorizer =
|
64 |
-
X = vectorizer.
|
65 |
-
|
66 |
story_points = model.predict(X)
|
67 |
return story_points
|
68 |
|
69 |
def calcula(titulo, descricao):
|
70 |
-
return calcula_MbR(titulo, descricao), calcula_neosp(titulo, descricao),
|
71 |
|
72 |
demo = gr.Interface(fn=calcula,
|
73 |
inputs=[gr.Textbox(placeholder="Título", label="Título"),
|
74 |
gr.Textbox(lines=10, placeholder="Descrição", label="Descrição")],
|
75 |
outputs=[gr.Textbox(label="Story Points Estimado MbR"),
|
76 |
-
gr.Textbox(label="Story Points Estimado NEOSP"),
|
77 |
-
gr.Textbox(label="Story Points Estimado TFIDF-
|
78 |
title="Agile Task Story Point Estimator - TAWOS - Alloy",
|
79 |
-
examples=[[
|
80 |
)
|
81 |
|
82 |
-
demo.launch()
|
|
|
10 |
from textblob import TextBlob
|
11 |
import textstat
|
12 |
|
13 |
+
titulo1 = """CLONE - Studio Dashboard: "default" and "Default Project" does not give clear information about Alloy and Project unless description is read."""
|
14 |
+
descricao1 = """Steps To Reproduce: 1. On dashboard on studio 3.0, navigate to Develop tab. 2. Notice "default" and "Default Project" & "two-tabbed" and "Tabbed Application" names. Actual: User does not get clear information from names that one is alloy project and another one is Titanium project unless he reads the description below. Expected: Naming convention or icon corresponding must suggest type"""
|
15 |
|
16 |
+
titulo2 = """Ti.UI.Picker has no collection binding"""
|
17 |
+
descricao2 = """h3. original discussion http://developer.appcelerator.com/question/145992/databinding-on-picker h3. problem Collection binding is not implemented for Ti.UI.Picker as it is for Ti.UI.TableView and other generic Titaniums views (View, Window, ScrollView, etc...). h3. solution Support collection binding on Ti.UI.Picker just as it is on TableView. It will need special handling as the Ti.UI.Picker requires custom parsing for columns and rows. Something like this should be how it would work for devs: {code:xml} <Alloy> <Collection src="book" /> <Window class="container"> <Picker dataCollection="book"> <PickerRow title="{title}" /> </Picker> </Window> </Alloy> {code}"""
|
18 |
|
19 |
+
titulo3 = """Enable more complex notation in binding"""
|
20 |
+
descricao3 = """Allow developers to use syntax like the following in collection/model bindings: {code:xml} <Alloy> <Model src=""someModel""/> <Window title=""{someModel.title} {someModel.subtitle}""/> </Alloy> {code} Basically, instead of assuming the whole property needs to be wrapped in \{\}, allow developers to put as many of them in the attribute as they want."""
|
21 |
+
|
22 |
+
titulo4 = """Orphan file cleanup deletes builtins and widget assets"""
|
23 |
+
descricao4 = """During the compile process Alloy will attempt to remove files from the Resources directory that are no longer present anywhere in the ""app"" folder. Alloy searches a number of locations in the ""app"" folder to see if the file is an orphan or not. False negatives should be avoided as they will leave unused files in the project. False positives on the other hand are not really worrisome since those resources will be recreated on the next compile anyway. With that in mind, there are currently false positives for orphan file deletion for builtins and widgets. Builtins and widgets will be pulled in fresh each time. Again, this will not negatively impact a developer's build process or app in any way, it would just be more true to the logic if these files were left alone during the orphan cleanup phase."""
|
24 |
+
|
25 |
+
titulo5 = """Resolve suboptimal compression from uglify-js v2 update"""
|
26 |
+
descricao5 = """The v2 update of uglify-js in Alloy, specifically version 2.2.5, has some suboptimal compressions, which are causing the optimizer.js test spec to fail in certain cases. Specifically the issues are around booleans and cascading of variables in assignments. These issues have been logged with the Uglifyjs2 project in the following links: * https://github.com/mishoo/UglifyJS2/issues/137 * https://github.com/mishoo/UglifyJS2/issues/138 When these issues are resolved and distributed in an npm release, we need to revisit these compressions and testing to ensure that the fixes are in place, and that new uglify-js version has no regressions that impact alloy."""
|
27 |
|
28 |
def calcula_MbR(titulo, descricao):
|
29 |
context = titulo + descricao
|
|
|
62 |
return story_points
|
63 |
|
64 |
def calculaTFIDFSVM(titulo, descricao):
|
65 |
+
model = load("model/model_tawos_aloy_tfidfsvm.pkl")
|
66 |
context = titulo + descricao
|
67 |
d = {"context": [context]}
|
68 |
df = pd.DataFrame(data=d, columns=["context"])
|
69 |
+
vectorizer = load("model/vectorizer_tfidf.pkl")
|
70 |
+
X = vectorizer.transform(df["context"])
|
71 |
+
|
72 |
story_points = model.predict(X)
|
73 |
return story_points
|
74 |
|
75 |
def calcula(titulo, descricao):
|
76 |
+
return calcula_MbR(titulo, descricao), calcula_neosp(titulo, descricao), calculaTFIDFSVM(titulo, descricao)
|
77 |
|
78 |
demo = gr.Interface(fn=calcula,
|
79 |
inputs=[gr.Textbox(placeholder="Título", label="Título"),
|
80 |
gr.Textbox(lines=10, placeholder="Descrição", label="Descrição")],
|
81 |
outputs=[gr.Textbox(label="Story Points Estimado MbR"),
|
82 |
+
gr.Textbox(label="Story Points Estimado NEOSP-SVR"),
|
83 |
+
gr.Textbox(label="Story Points Estimado TFIDF-SVR")],
|
84 |
title="Agile Task Story Point Estimator - TAWOS - Alloy",
|
85 |
+
examples=[[titulo1, descricao1], [titulo2, descricao2], [titulo3, descricao3], [titulo4, descricao4], [titulo5, descricao5]]
|
86 |
)
|
87 |
|
88 |
+
demo.launch(server_port=8080)
|
dataset/ALOY_deep-se.csv
CHANGED
@@ -1,7 +1,7 @@
|
|
1 |
"issuekey","created","title","description","storypoint"
|
2 |
"ALOY-344","10/24/2012 23:41:49","CLONE - Studio Dashboard: ""default"" and ""Default Project"" does not give clear information about Alloy and Project unless description is read.","Steps To Reproduce: 1. On dashboard on studio 3.0, navigate to Develop tab. 2. Notice ""default"" and ""Default Project"" & ""two-tabbed"" and ""Tabbed Application"" names. Actual: User does not get clear information from names that one is alloy project and another one is Titanium project unless he reads the description below. Expected: Naming convention or icon corresponding must suggest type of Project.",8
|
3 |
"ALOY-440","12/20/2012 17:21:38","Ti.UI.Picker has no collection binding","h3. original discussion http://developer.appcelerator.com/question/145992/databinding-on-picker h3. problem Collection binding is not implemented for Ti.UI.Picker as it is for Ti.UI.TableView and other generic Titaniums views (View, Window, ScrollView, etc...). h3. solution Support collection binding on Ti.UI.Picker just as it is on TableView. It will need special handling as the Ti.UI.Picker requires custom parsing for columns and rows. Something like this should be how it would work for devs: {code:xml} <Alloy> <Collection src=""book"" /> <Window class=""container""> <Picker dataCollection=""book""> <PickerRow title=""{title}"" /> </Picker> </Window> </Alloy> {code}",8
|
4 |
-
"ALOY-443","12/21/2012 13:41:13","
|
5 |
"ALOY-488","01/26/2013 22:14:34","Orphan file cleanup deletes builtins and widget assets","During the compile process Alloy will attempt to remove files from the Resources directory that are no longer present anywhere in the ""app"" folder. Alloy searches a number of locations in the ""app"" folder to see if the file is an orphan or not. False negatives should be avoided as they will leave unused files in the project. False positives on the other hand are not really worrisome since those resources will be recreated on the next compile anyway. With that in mind, there are currently false positives for orphan file deletion for builtins and widgets. Builtins and widgets will be pulled in fresh each time. Again, this will not negatively impact a developer's build process or app in any way, it would just be more true to the logic if these files were left alone during the orphan cleanup phase.",3
|
6 |
"ALOY-540","03/01/2013 19:25:27","Resolve suboptimal compression from uglify-js v2 update","The v2 update of uglify-js in Alloy, specifically version 2.2.5, has some suboptimal compressions, which are causing the optimizer.js test spec to fail in certain cases. Specifically the issues are around booleans and cascading of variables in assignments. These issues have been logged with the Uglifyjs2 project in the following links: * https://github.com/mishoo/UglifyJS2/issues/137 * https://github.com/mishoo/UglifyJS2/issues/138 When these issues are resolved and distributed in an npm release, we need to revisit these compressions and testing to ensure that the fixes are in place, and that new uglify-js version has no regressions that impact alloy.",5
|
7 |
"ALOY-544","03/07/2013 01:14:43","Ability to define a custom namespace to enable Alloy to generate custom widgets","Alloy should allow the user to specify a custom namespace for each widget in XML which modifies the generated code to use the widgets within the specified namespace. As an example, <Window id=""win""> generates Ti.UI.createwindow(). The user should be able to specify <Window ns=""mcd"" id=""win""/>, which Alloy would in turn use to generate mcd.createwindow(). This is useful if the user has their own custom framework with custom widget attributes.",3
|
|
|
1 |
"issuekey","created","title","description","storypoint"
|
2 |
"ALOY-344","10/24/2012 23:41:49","CLONE - Studio Dashboard: ""default"" and ""Default Project"" does not give clear information about Alloy and Project unless description is read.","Steps To Reproduce: 1. On dashboard on studio 3.0, navigate to Develop tab. 2. Notice ""default"" and ""Default Project"" & ""two-tabbed"" and ""Tabbed Application"" names. Actual: User does not get clear information from names that one is alloy project and another one is Titanium project unless he reads the description below. Expected: Naming convention or icon corresponding must suggest type of Project.",8
|
3 |
"ALOY-440","12/20/2012 17:21:38","Ti.UI.Picker has no collection binding","h3. original discussion http://developer.appcelerator.com/question/145992/databinding-on-picker h3. problem Collection binding is not implemented for Ti.UI.Picker as it is for Ti.UI.TableView and other generic Titaniums views (View, Window, ScrollView, etc...). h3. solution Support collection binding on Ti.UI.Picker just as it is on TableView. It will need special handling as the Ti.UI.Picker requires custom parsing for columns and rows. Something like this should be how it would work for devs: {code:xml} <Alloy> <Collection src=""book"" /> <Window class=""container""> <Picker dataCollection=""book""> <PickerRow title=""{title}"" /> </Picker> </Window> </Alloy> {code}",8
|
4 |
+
"ALOY-443","12/21/2012 13:41:13","E1nable more complex notation in binding","Allow developers to use syntax like the following in collection/model bindings: {code:xml} <Alloy> <Model src=""someModel""/> <Window title=""{someModel.title} {someModel.subtitle}""/> </Alloy> {code} Basically, instead of assuming the whole property needs to be wrapped in \{\}, allow developers to put as many of them in the attribute as they want.",8
|
5 |
"ALOY-488","01/26/2013 22:14:34","Orphan file cleanup deletes builtins and widget assets","During the compile process Alloy will attempt to remove files from the Resources directory that are no longer present anywhere in the ""app"" folder. Alloy searches a number of locations in the ""app"" folder to see if the file is an orphan or not. False negatives should be avoided as they will leave unused files in the project. False positives on the other hand are not really worrisome since those resources will be recreated on the next compile anyway. With that in mind, there are currently false positives for orphan file deletion for builtins and widgets. Builtins and widgets will be pulled in fresh each time. Again, this will not negatively impact a developer's build process or app in any way, it would just be more true to the logic if these files were left alone during the orphan cleanup phase.",3
|
6 |
"ALOY-540","03/01/2013 19:25:27","Resolve suboptimal compression from uglify-js v2 update","The v2 update of uglify-js in Alloy, specifically version 2.2.5, has some suboptimal compressions, which are causing the optimizer.js test spec to fail in certain cases. Specifically the issues are around booleans and cascading of variables in assignments. These issues have been logged with the Uglifyjs2 project in the following links: * https://github.com/mishoo/UglifyJS2/issues/137 * https://github.com/mishoo/UglifyJS2/issues/138 When these issues are resolved and distributed in an npm release, we need to revisit these compressions and testing to ensure that the fixes are in place, and that new uglify-js version has no regressions that impact alloy.",5
|
7 |
"ALOY-544","03/07/2013 01:14:43","Ability to define a custom namespace to enable Alloy to generate custom widgets","Alloy should allow the user to specify a custom namespace for each widget in XML which modifies the generated code to use the widgets within the specified namespace. As an example, <Window id=""win""> generates Ti.UI.createwindow(). The user should be able to specify <Window ns=""mcd"" id=""win""/>, which Alloy would in turn use to generate mcd.createwindow(). This is useful if the user has their own custom framework with custom widget attributes.",3
|
gerar_modelos/gerar_modelos_mbr.py
ADDED
@@ -0,0 +1,22 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
from sklearn.dummy import DummyRegressor
|
2 |
+
import pandas as pd
|
3 |
+
from nltk.corpus import stopwords
|
4 |
+
from joblib import dump
|
5 |
+
|
6 |
+
# carregando os dados
|
7 |
+
df = pd.read_csv("dataset/ALOY_deep-se.csv")
|
8 |
+
|
9 |
+
# Tirando os 5 Primeiros
|
10 |
+
df = df.iloc[5:df.shape[0]]
|
11 |
+
|
12 |
+
# criando a coluna contexto = titulo + descricao
|
13 |
+
df["context"] = df["title"] + df["description"]
|
14 |
+
|
15 |
+
X = df["storypoint"].index
|
16 |
+
y = df["storypoint"]
|
17 |
+
|
18 |
+
model = DummyRegressor(strategy="mean")
|
19 |
+
model.fit(X, y)
|
20 |
+
|
21 |
+
dump(model, "model/model_tawos_aloy_mbr.pkl")
|
22 |
+
|
gerar_modelos/gerar_modelos_neosp.py
ADDED
@@ -0,0 +1,45 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
from textblob import TextBlob
|
2 |
+
import textstat
|
3 |
+
from sklearn import svm
|
4 |
+
import pandas as pd
|
5 |
+
import nltk
|
6 |
+
from nltk.corpus import stopwords
|
7 |
+
from joblib import dump
|
8 |
+
|
9 |
+
# carregando os dados
|
10 |
+
df = pd.read_csv("dataset/ALOY_deep-se.csv")
|
11 |
+
|
12 |
+
# Tirando os 5 Primeiros
|
13 |
+
df = df.iloc[5:df.shape[0]]
|
14 |
+
|
15 |
+
# criando a coluna contexto = titulo + descricao
|
16 |
+
df["context"] = df["title"] + df["description"]
|
17 |
+
|
18 |
+
# pré-processamento
|
19 |
+
nltk.download('stopwords')
|
20 |
+
stop = stopwords.words('english')
|
21 |
+
df['context'] = df['context'].apply(lambda x: ' '.join([word for word in x.split() if word not in (stop)]))
|
22 |
+
|
23 |
+
# Extração de features
|
24 |
+
df["gunning_fog"] = df['context'].apply(textstat.gunning_fog)
|
25 |
+
df["flesch_reading_ease"] = df['context'].apply(textstat.flesch_reading_ease)
|
26 |
+
df["flesch_kincaid_grade"] = df['context'].apply(textstat.flesch_kincaid_grade)
|
27 |
+
df["smog_index"] = df['context'].apply(textstat.smog_index)
|
28 |
+
df["coleman_liau_index"] = df['context'].apply(textstat.coleman_liau_index)
|
29 |
+
df["automated_readability_index"] = df['context'].apply(textstat.automated_readability_index)
|
30 |
+
df["dale_chall_readability_score"] = df['context'].apply(textstat.dale_chall_readability_score)
|
31 |
+
df["difficult_words"] = df['context'].apply(textstat.difficult_words)
|
32 |
+
df["linsear_write_formula"] = df['context'].apply(textstat.linsear_write_formula)
|
33 |
+
df["polarity"] = df["context"].apply(lambda x: TextBlob(x).sentiment.polarity)
|
34 |
+
df["subjectivity"] = df["context"].apply(lambda x: TextBlob(x).sentiment.subjectivity)
|
35 |
+
|
36 |
+
X = df[["gunning_fog", "flesch_reading_ease", "flesch_kincaid_grade", "smog_index", "coleman_liau_index",
|
37 |
+
"automated_readability_index", "dale_chall_readability_score", "difficult_words", "linsear_write_formula",
|
38 |
+
"polarity", "subjectivity"]]
|
39 |
+
y = df["storypoint"]
|
40 |
+
|
41 |
+
# modelo SVR
|
42 |
+
model = svm.SVR()
|
43 |
+
model.fit(X, y)
|
44 |
+
|
45 |
+
dump(model, "model/model_tawos_aloy_neosp.pkl")
|
gerar_modelos/gerar_modelos_tfidfsvm.py
ADDED
@@ -0,0 +1,36 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
from sklearn.feature_extraction.text import TfidfVectorizer
|
2 |
+
from sklearn import svm
|
3 |
+
import pandas as pd
|
4 |
+
import nltk
|
5 |
+
from nltk.corpus import stopwords
|
6 |
+
from joblib import dump
|
7 |
+
|
8 |
+
# Carregando os dados
|
9 |
+
df = pd.read_csv("dataset/ALOY_deep-se.csv")
|
10 |
+
|
11 |
+
# Tirando os 5 Primeiros
|
12 |
+
df = df.iloc[5:df.shape[0]]
|
13 |
+
|
14 |
+
# Criando a coluna contexto = titulo + descricao
|
15 |
+
df["context"] = df["title"] + df["description"]
|
16 |
+
|
17 |
+
# Pré-processamento
|
18 |
+
nltk.download('stopwords')
|
19 |
+
stop = stopwords.words('english')
|
20 |
+
df['context'] = df['context'].apply(lambda x: ' '.join([word for word in x.split() if word not in (stop)]))
|
21 |
+
|
22 |
+
# Extração de features
|
23 |
+
vectorizer = TfidfVectorizer()
|
24 |
+
X = vectorizer.fit_transform(df["context"])
|
25 |
+
y = df["storypoint"]
|
26 |
+
|
27 |
+
# Modelos
|
28 |
+
model = svm.SVR()
|
29 |
+
model.fit(X, y)
|
30 |
+
|
31 |
+
dump(vectorizer, "model/vectorizer_tfidf.pkl")
|
32 |
+
dump(model, "model/model_tawos_aloy_tfidfsvm.pkl")
|
33 |
+
|
34 |
+
|
35 |
+
|
36 |
+
|
gerar_modelos/temp.py
ADDED
@@ -0,0 +1,13 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
from sklearn.dummy import DummyRegressor
|
2 |
+
import pandas as pd
|
3 |
+
from nltk.corpus import stopwords
|
4 |
+
from joblib import dump
|
5 |
+
|
6 |
+
# carregando os dados
|
7 |
+
df = pd.read_csv("dataset/ALOY_deep-se.csv")
|
8 |
+
|
9 |
+
print(df.shape)
|
10 |
+
|
11 |
+
df = df.iloc[1:df.shape[0]]
|
12 |
+
|
13 |
+
print(df.shape)
|
model/model_tawos_aloy_mbr.pkl
CHANGED
@@ -1,3 +1,3 @@
|
|
1 |
version https://git-lfs.github.com/spec/v1
|
2 |
-
oid sha256:
|
3 |
size 383
|
|
|
1 |
version https://git-lfs.github.com/spec/v1
|
2 |
+
oid sha256:caf24da2287096a50a79a061a89a97b3754e97a73e761b347209441e4f4a8a5d
|
3 |
size 383
|
model/model_tawos_aloy_neosp.pkl
CHANGED
@@ -1,3 +1,3 @@
|
|
1 |
version https://git-lfs.github.com/spec/v1
|
2 |
-
oid sha256:
|
3 |
-
size
|
|
|
1 |
version https://git-lfs.github.com/spec/v1
|
2 |
+
oid sha256:af24bfeaf71ddd9722eba995ddc99afe0c8b106785dac50818218a3d9d963d83
|
3 |
+
size 22883
|
model/{model_tawos_aloy_tfidf_svm.pkl → model_tawos_aloy_tfidfsvm.pkl}
RENAMED
@@ -1,3 +1,3 @@
|
|
1 |
version https://git-lfs.github.com/spec/v1
|
2 |
-
oid sha256:
|
3 |
-
size
|
|
|
1 |
version https://git-lfs.github.com/spec/v1
|
2 |
+
oid sha256:a56d344541d9f8ac65460dd19e9702f8aaafcea26579957f9460ef0b3d0abebf
|
3 |
+
size 141035
|
model/vectorizer_tfidf.pkl
ADDED
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
1 |
+
version https://git-lfs.github.com/spec/v1
|
2 |
+
oid sha256:2b41fefa5560f7e858462dad642e89e5274da92e03ab69291e18127a835fad5f
|
3 |
+
size 102859
|