Summary form only given. Quality software is software that is fit for its intended purpose. High quality software meets business goals and user needs, which means it has the right features and the right attributes. Building quality software requires using disciplined processes and a carefully designed software architecture. The architecture part of this quality equation has often been ignored in software engineering education. Too often we teach only low-level code design. Yet, the software architecture is the first design artifact that addresses key quality attributes such as affordability, reliability, security, modifiability, and performance. The quality of a system emanates in large part from the software architecture. The software architecture provides the most fundamental basis for communicating design decisions and establishing effective work breakdown structures. The software architecture is the reusable, transferable abstraction that is the basis for software product lines. Architecture represents an enormous risk in a software development project; the wrong architecture leads to poor quality software and very often to project failure. It's time that all software engineering students know the principles of software architecture and how to use effective architecture practices. Every facet of our society depends on software. To ensure high quality software we need to teach our students to architect high quality software.
{"title":"Let's Teach Architecting High Quality Software","authors":"Linda M. Northrop","doi":"10.1109/CSEET.2006.23","DOIUrl":"https://doi.org/10.1109/CSEET.2006.23","url":null,"abstract":"Summary form only given. Quality software is software that is fit for its intended purpose. High quality software meets business goals and user needs, which means it has the right features and the right attributes. Building quality software requires using disciplined processes and a carefully designed software architecture. The architecture part of this quality equation has often been ignored in software engineering education. Too often we teach only low-level code design. Yet, the software architecture is the first design artifact that addresses key quality attributes such as affordability, reliability, security, modifiability, and performance. The quality of a system emanates in large part from the software architecture. The software architecture provides the most fundamental basis for communicating design decisions and establishing effective work breakdown structures. The software architecture is the reusable, transferable abstraction that is the basis for software product lines. Architecture represents an enormous risk in a software development project; the wrong architecture leads to poor quality software and very often to project failure. It's time that all software engineering students know the principles of software architecture and how to use effective architecture practices. Every facet of our society depends on software. To ensure high quality software we need to teach our students to architect high quality software.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2006-04-19","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117143210","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Computer science and software engineering curricula are, by now, long established in most institutions of higher learning. They have evolved from a few utilitarian courses that taught essential programming skills to fully-fledged academic fourand even five-year programs to match the growing body of experience and knowledge in the field. Yet, it seems that some quite fundamental gaps persist in the education of software experts rendering many of them inadequately prepared for industrial software development. These problems, which are both technical and cultural, can be addressed only if there is a clearer understanding of the nature of software technology. Knowing how software differs from traditional technologies will indicate where innovative approaches to teaching are necessary, whereas knowing how it is similar to those technologies will help us understand where classical time-proven methods can be applied. This talk identifies some of the key problem areas in current curricula and describes suggestions for dealing with them from the perspective of a long-term practitioner of industrial software development. Bio: Bran Selic is an IBM Distinguished Engineer at IBM Rational and an adjunct professor at Carleton University in Ottawa, Canada. He has over 30 years of experience in designing and implementing largescale industrial software systems. Bran pioneered the application of model-driven development methods in real-time applications. He is chair of the OMG team responsible for the UML 2.0 standard. Proceedings of the 18th Conference on Software Engineering Education & Training (CSEET’05) 1093-0175/05 $ 20.00 IEEE
{"title":"What I Wish I Had Learned in School: Reflections on 30+ Years as a Software Developer","authors":"B. Selić","doi":"10.1109/CSEET.2005.43","DOIUrl":"https://doi.org/10.1109/CSEET.2005.43","url":null,"abstract":"Computer science and software engineering curricula are, by now, long established in most institutions of higher learning. They have evolved from a few utilitarian courses that taught essential programming skills to fully-fledged academic fourand even five-year programs to match the growing body of experience and knowledge in the field. Yet, it seems that some quite fundamental gaps persist in the education of software experts rendering many of them inadequately prepared for industrial software development. These problems, which are both technical and cultural, can be addressed only if there is a clearer understanding of the nature of software technology. Knowing how software differs from traditional technologies will indicate where innovative approaches to teaching are necessary, whereas knowing how it is similar to those technologies will help us understand where classical time-proven methods can be applied. This talk identifies some of the key problem areas in current curricula and describes suggestions for dealing with them from the perspective of a long-term practitioner of industrial software development. Bio: Bran Selic is an IBM Distinguished Engineer at IBM Rational and an adjunct professor at Carleton University in Ottawa, Canada. He has over 30 years of experience in designing and implementing largescale industrial software systems. Bran pioneered the application of model-driven development methods in real-time applications. He is chair of the OMG team responsible for the UML 2.0 standard. Proceedings of the 18th Conference on Software Engineering Education & Training (CSEET’05) 1093-0175/05 $ 20.00 IEEE","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-04-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130093368","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Alas, the stereotypical software engineer is depicted as spending long hours working alone in a cubicle filled with empty pizza boxes and soda cans. This "work alone" stereotype can dissuade talented individuals from considering a career in the information technology industry. As educators, we often reinforce this "geek" stereotype early in the curriculum by giving students lengthy assignments and forcing them to work alone — collaborating is cheating! However in industry, software engineers actually spend a large part of their day collaborating with teammates — the "work alone" stereotype is largely unfounded. Research results indicate that through providing students with more collaborative experiences, we could retain more students without compromising their individual learning and these students would be better prepared to be collaborative team members. Bio: Laurie Williams is an Assistant Professor at North Carolina State University. She received her undergraduate degree in Industrial Engineering from Lehigh University. She also received an MBA from Duke University and a Ph.D. in Computer Science from the University of Utah. Prior to returning to academia to obtain her Ph.D., she worked in industry, for IBM, for nine years. Dr. Williams research interests include empirical studies of agile software development including the pair programming and test-driven development practices, software reliability, software testing, and software security. Proceedings of the 18th Conference on Software Engineering Education & Training (CSEET’05) 1093-0175/05 $ 20.00 IEEE
{"title":"Debunking the Geek Stereotype with Software Engineering Education","authors":"L. Williams","doi":"10.1109/CSEET.2005.15","DOIUrl":"https://doi.org/10.1109/CSEET.2005.15","url":null,"abstract":"Alas, the stereotypical software engineer is depicted as spending long hours working alone in a cubicle filled with empty pizza boxes and soda cans. This \"work alone\" stereotype can dissuade talented individuals from considering a career in the information technology industry. As educators, we often reinforce this \"geek\" stereotype early in the curriculum by giving students lengthy assignments and forcing them to work alone — collaborating is cheating! However in industry, software engineers actually spend a large part of their day collaborating with teammates — the \"work alone\" stereotype is largely unfounded. Research results indicate that through providing students with more collaborative experiences, we could retain more students without compromising their individual learning and these students would be better prepared to be collaborative team members. Bio: Laurie Williams is an Assistant Professor at North Carolina State University. She received her undergraduate degree in Industrial Engineering from Lehigh University. She also received an MBA from Duke University and a Ph.D. in Computer Science from the University of Utah. Prior to returning to academia to obtain her Ph.D., she worked in industry, for IBM, for nine years. Dr. Williams research interests include empirical studies of agile software development including the pair programming and test-driven development practices, software reliability, software testing, and software security. Proceedings of the 18th Conference on Software Engineering Education & Training (CSEET’05) 1093-0175/05 $ 20.00 IEEE","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"10 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-04-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134087831","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
M. Lemay, Ray Barham, C. Zinck, P. Bassett, R. LeBlanc
The purpose of this panel is to inform attendees about the current state of the accreditation of software engineering programs and licensing for software engineers in Canada and the US. We also intend to stimulate discussion of the more controversial aspects of this topic.
{"title":"Professional Engineering and Software Engineering","authors":"M. Lemay, Ray Barham, C. Zinck, P. Bassett, R. LeBlanc","doi":"10.1109/CSEET.2005.25","DOIUrl":"https://doi.org/10.1109/CSEET.2005.25","url":null,"abstract":"The purpose of this panel is to inform attendees about the current state of the accreditation of software engineering programs and licensing for software engineers in Canada and the US. We also intend to stimulate discussion of the more controversial aspects of this topic.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"35 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-04-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130665854","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Bio: Debra J. Richardson is the Ted and Janice Smith Family Foundation Dean and Professor of Donald Bren School of Information and Computer Sciences at the University of California at Irvine. She received her PhD in Computer and Information Science at the University of Massachusetts in 1981. She joined the UCI faculty in 1987. Dr. Richardson pioneered research in “specification-based testing”, whereby formal specifications and methods are employed to guide and evaluate software testing and analysis. She has been investigating software testing for over 15 years. Her current work focuses on enabling specification-based testing technology throughout the software lifecycle, from requirements and architecture analysis through operation and evolution. She has developed leading edge tools, and has worked with several companies in adopting technology to improve the quality of critical software systems. Dr. Richardson has worked with several companies in adopting technology for improving the quality of their software products and processes. She is currently director of MICRO (Microelectronics Innovation and Computer Research Opportunities), the first industry-university cooperative research program in the University of California. Proceedings of the 18th Conference on Software Engineering Education & Training (CSEET’05) 1093-0175/05 $ 20.00 IEEE
Debra J. Richardson是Ted和Janice Smith家庭基金会的院长,也是加州大学欧文分校唐纳德·布伦信息与计算机科学学院的教授。她于1981年获得麻省大学计算机与信息科学博士学位。她于1987年加入加州大学洛杉矶分校。Richardson博士开创了“基于规范的测试”的研究,即采用正式的规范和方法来指导和评估软件测试和分析。她研究软件测试已经超过15年了。她目前的工作重点是在整个软件生命周期中启用基于规范的测试技术,从需求和架构分析到操作和演进。她开发了领先的工具,并与几家公司合作采用技术来提高关键软件系统的质量。Richardson博士曾与几家公司合作,采用技术来提高软件产品和过程的质量。她目前是加州大学第一个产学研合作项目MICRO(微电子创新和计算机研究机会)的主任。第十八届软件工程教育与培训会议论文集(CSEET ' 05) 1093-0175/05 $ 20.00 IEEE
{"title":"Informatics: Contextualizing Computer Science and Software Engineering Education","authors":"D. Richardson","doi":"10.1109/CSEET.2005.21","DOIUrl":"https://doi.org/10.1109/CSEET.2005.21","url":null,"abstract":"Bio: Debra J. Richardson is the Ted and Janice Smith Family Foundation Dean and Professor of Donald Bren School of Information and Computer Sciences at the University of California at Irvine. She received her PhD in Computer and Information Science at the University of Massachusetts in 1981. She joined the UCI faculty in 1987. Dr. Richardson pioneered research in “specification-based testing”, whereby formal specifications and methods are employed to guide and evaluate software testing and analysis. She has been investigating software testing for over 15 years. Her current work focuses on enabling specification-based testing technology throughout the software lifecycle, from requirements and architecture analysis through operation and evolution. She has developed leading edge tools, and has worked with several companies in adopting technology to improve the quality of critical software systems. Dr. Richardson has worked with several companies in adopting technology for improving the quality of their software products and processes. She is currently director of MICRO (Microelectronics Innovation and Computer Research Opportunities), the first industry-university cooperative research program in the University of California. Proceedings of the 18th Conference on Software Engineering Education & Training (CSEET’05) 1093-0175/05 $ 20.00 IEEE","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"84 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-04-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116335813","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Software engineering processes for building safe and secure software have existed for a long time. However, these processes-particularly for secure software engineering-have not been widely taught within colleges and universities leading to a shortage of graduates skilled in these areas. This panel will discuss the increasing need for colleges and universities to produce graduates that are skilled in building safe and secure software. Panelists will share their experiences teaching courses in these areas and future directions for curricula.
{"title":"Software Assurance Education","authors":"S. Redwine, Hun Kim, Joe Saur, S. Butler","doi":"10.1109/CSEET.2005.28","DOIUrl":"https://doi.org/10.1109/CSEET.2005.28","url":null,"abstract":"Software engineering processes for building safe and secure software have existed for a long time. However, these processes-particularly for secure software engineering-have not been widely taught within colleges and universities leading to a shortage of graduates skilled in these areas. This panel will discuss the increasing need for colleges and universities to produce graduates that are skilled in building safe and secure software. Panelists will share their experiences teaching courses in these areas and future directions for curricula.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-04-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131339666","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2004-03-01DOI: 10.1109/CSEE.2004.1276525
G. Hislop, H. Ellis, Kathy S. Land, A. Moreno
Summary form only given. As the number of undergraduate software engineering programs increases, what does this imply about the future role of graduate programs in software engineering? This panel will explore changes that may be required to existing graduate software engineering programs to adapt to the increasing number of undergraduates with bachelor?s degrees in software engineering entering graduate software engineering programs. In particular, the questions the panel will consider include: How should graduate software engineering programs adapt to accommodate the arrival of students with BSSE degrees? Should graduate software engineering curricula change because of the growth in BSSE programs, and, if so, how? Should a BSSE degree substitute for the industry experience requirement commonly used in MSSE programs? Will graduate software engineering education still have value in industry for a BSSE graduate? What is the role of post-baccalaureate certificate programs in relation to graduate software engineering degree programs? How does the arrival of accreditation for software engineering impact graduate software engineering education? The panel participants have experience with both undergraduate and graduate software engineering education delivered in both degree and certificate programs. The panel has also been organized to include perspectives from the U.S. and Europe as well as a perspective from industry.
{"title":"Graduate Software Engineering Education: Adapting for the BSSE?","authors":"G. Hislop, H. Ellis, Kathy S. Land, A. Moreno","doi":"10.1109/CSEE.2004.1276525","DOIUrl":"https://doi.org/10.1109/CSEE.2004.1276525","url":null,"abstract":"Summary form only given. As the number of undergraduate software engineering programs increases, what does this imply about the future role of graduate programs in software engineering? This panel will explore changes that may be required to existing graduate software engineering programs to adapt to the increasing number of undergraduates with bachelor?s degrees in software engineering entering graduate software engineering programs. In particular, the questions the panel will consider include: How should graduate software engineering programs adapt to accommodate the arrival of students with BSSE degrees? Should graduate software engineering curricula change because of the growth in BSSE programs, and, if so, how? Should a BSSE degree substitute for the industry experience requirement commonly used in MSSE programs? Will graduate software engineering education still have value in industry for a BSSE graduate? What is the role of post-baccalaureate certificate programs in relation to graduate software engineering degree programs? How does the arrival of accreditation for software engineering impact graduate software engineering education? The panel participants have experience with both undergraduate and graduate software engineering education delivered in both degree and certificate programs. The panel has also been organized to include perspectives from the U.S. and Europe as well as a perspective from industry.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131852830","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2004-03-01DOI: 10.1109/CSEE.2004.1276503
G. McGraw
Software security has blossomed nicely in the last few years with the appearance of new textbooks, new courses, and a government mandate, yet there are many people still to be educated. Savvy security people from the operations side tend to decry the cluelessness of software developers, putting the blame for our current software problems squarely on the shoulders of the "builders." However, builders cannot rightly be blamed for their lack of security knowledge, because security is only rarely a part of any standard curriculum. Getting the security message to developers, architects and other builders is an essential aspect of addressing the software security problem. Awareness training for software professionals is one way to do this. Integrating security thinking into the academic curriculum is another.
{"title":"Software Security Clue Distribution","authors":"G. McGraw","doi":"10.1109/CSEE.2004.1276503","DOIUrl":"https://doi.org/10.1109/CSEE.2004.1276503","url":null,"abstract":"Software security has blossomed nicely in the last few years with the appearance of new textbooks, new courses, and a government mandate, yet there are many people still to be educated. Savvy security people from the operations side tend to decry the cluelessness of software developers, putting the blame for our current software problems squarely on the shoulders of the \"builders.\" However, builders cannot rightly be blamed for their lack of security knowledge, because security is only rarely a part of any standard curriculum. Getting the security message to developers, architects and other builders is an essential aspect of addressing the software security problem. Awareness training for software professionals is one way to do this. Integrating security thinking into the academic curriculum is another.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"73 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131030492","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2004-03-01DOI: 10.1109/CSEE.2004.1276502
F. Anger
The article describes three significant and peculiar characteristics of software engineering which profoundly impact the way in which should think about software education: the effectiveness of current practice, the precipitous rate of change in the meaning of "software", and the gulf between software engineering research and practice.
{"title":"Will the Real Software Engineer Please Stand Up?","authors":"F. Anger","doi":"10.1109/CSEE.2004.1276502","DOIUrl":"https://doi.org/10.1109/CSEE.2004.1276502","url":null,"abstract":"The article describes three significant and peculiar characteristics of software engineering which profoundly impact the way in which should think about software education: the effectiveness of current practice, the precipitous rate of change in the meaning of \"software\", and the gulf between software engineering research and practice.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"32 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124595628","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2003-03-20DOI: 10.1109/CSEET.2003.10005
J. Kramer
Summary form only given, as follows. Abstraction is a key skill for software engineers. It is essential during requirements engineering to elicit the critical aspects of the environment and required system while neglecting the unimportant. At design time, we need to articulate the software architecture and component functionalities which satisfy functional and nonfunctional requirements while avoiding unnecessary implementation constraints. Even at the implementation stage we use data abstraction and classes so as to generalize solutions However, my experience is that abstraction is extremely difficult to teach and learn. How should we go about teaching this skill? Indeed, is it teachable? This talk discusses the difficulties and challenges in learning and using abstraction. In particular, we consider whether or not the standard engineering technique of model construction and analysis can help in this venture. The importance of having associated tool support is also considered.
{"title":"Abstraction - is it teachable? 'the devil is in the detail'","authors":"J. Kramer","doi":"10.1109/CSEET.2003.10005","DOIUrl":"https://doi.org/10.1109/CSEET.2003.10005","url":null,"abstract":"Summary form only given, as follows. Abstraction is a key skill for software engineers. It is essential during requirements engineering to elicit the critical aspects of the environment and required system while neglecting the unimportant. At design time, we need to articulate the software architecture and component functionalities which satisfy functional and nonfunctional requirements while avoiding unnecessary implementation constraints. Even at the implementation stage we use data abstraction and classes so as to generalize solutions However, my experience is that abstraction is extremely difficult to teach and learn. How should we go about teaching this skill? Indeed, is it teachable? This talk discusses the difficulties and challenges in learning and using abstraction. In particular, we consider whether or not the standard engineering technique of model construction and analysis can help in this venture. The importance of having associated tool support is also considered.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"441 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-03-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133469535","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}