giseldo commited on
Commit
1549063
·
1 Parent(s): 2aa8b56

ultima mensagem

Browse files
__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
- titulo = """CLONE - Studio Dashboard: "default" and "Default Project" does not give clear information about Alloy and Project unless description is read."""
14
- descricao = """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
- titulo1 = """Ti.UI.Picker has no collection binding"""
17
- descricao1 = """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
- titulo2 = """Enable more complex notation in binding"""
20
- descricao2 = """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
  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/model_tawos_aloy_tfidf_svm.pkl.pkl")
60
  context = titulo + descricao
61
  d = {"context": [context]}
62
  df = pd.DataFrame(data=d, columns=["context"])
63
- vectorizer = TfidfVectorizer()
64
- X = vectorizer.fit_transform(df["context"])
65
- #X_new = SelectKBest(f_classif, k=50).fit_transfor(X)
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), 0
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-SVM")],
78
  title="Agile Task Story Point Estimator - TAWOS - Alloy",
79
- examples=[[titulo, descricao], [titulo1, descricao1], [titulo2, descricao2]]
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","Enable 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
 
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:78370715400e421619c699d1ac6b36b751eb479eaba46f024d70f12cc90fbfa2
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:3760ed763dea97ced7f0b1418fbbe01cb44245cf1cfac65fbf1ba524f3399881
3
- size 15627
 
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:eec214d79758da785f259815f1e4f9576f75b574f4d2173d703eb7f856c207d3
3
- size 4451
 
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