scispace - formally typeset
SciSpace - Your AI assistant to discover and understand research papers | Product Hunt

Proceedings ArticleDOI

If you're not modeling, you're just programming: modeling throughout an undergraduate software engineering program

01 Oct 2006-pp 291-300

TL;DR: This paper describes how RIT's software engineering program has placed modeling in most aspects of its curriculum and details the specific pedagogy that is used in several courses to teach students how to create, analyze and implement models of software systems.

AbstractModeling is a hallmark of the practice of engineering. Through centuries, engineers have used models ranging from informal "back of the envelope" scribbles to formal, verifiable mathematical models. Whether circuit models in electrical engineering, heat-transfer models in mechanical engineering, or queuing theory models in industrial engineering, modeling makes it possible to perform rigorous analysis that is the cornerstone of modern engineering. By considering software development as fundamentally an engineering endeavor, RIT's software engineering program strives to instill a culture of engineering practice by exposing our students to both formal and informal modeling of software systems throughout the entire curriculum. This paper describes how we have placed modeling in most aspects of our curriculum. The paper also details the specific pedagogy that we use in several courses to teach our students how to create, analyze and implement models of software systems.

...read more

Content maybe subject to copyright    Report

Citations
More filters

Journal Article
TL;DR: This study reviews several of the most commonly used inductive teaching methods, including inquiry learning, problem-based learning, project-basedLearning, case-based teaching, discovery learning, and just-in-time teaching, and defines each method, highlights commonalities and specific differences, and reviews research on the effectiveness.
Abstract: Traditional engineering instruction is deductive, beginning with theories and progressing to the applications of those theories Alternative teaching approaches are more inductive Topics are introduced by presenting specific observations, case studies or problems, and theories are taught or the students are helped to discover them only after the need to know them has been established This study reviews several of the most commonly used inductive teaching methods, including inquiry learning, problem-based learning, project-based learning, case-based teaching, discovery learning, and just-in-time teaching The paper defines each method, highlights commonalities and specific differences, and reviews research on the effectiveness of the methods While the strength of the evidence varies from one method to another, inductive methods are consistently found to be at least equal to, and in general more effective than, traditional deductive methods for achieving a broad range of learning outcomes

1,673 citations


Journal ArticleDOI
TL;DR: The needs of professional software development are addressed, and the next generation of software development tools are developed to address these needs.
Abstract: Addressing the needs of professional software development.

30 citations


01 Jan 2005
Abstract: At the Rochester Institute of Technology, the undergraduate introductory software engineering course has been redesigned from a lecture-lab format to a project-centric studio format. The new format blends the lecture material with the project work. As a result, students drive their own learning experience based on scaffolding created by the course design. The challenges faced and the techniques and strategies utilized in the planning and delivery of the course will be discussed, including the utilization of online learning support infrastructure. This paper presents instructor experiences, analysis of student feedback, lessons learned and recommendations for other educators considering an active learning approach for their courses.

25 citations


01 Jan 2012
Abstract: Modeling is a key skill in software development. The ability to develop, manipulate and understand models for software is therefore an important learning objective in many CS/SE courses. In this working group, we investigated how and when (software) modeling is taught to help us better understand the key issues in teaching (software) modeling. Several shortcomings were found in common curricula, both in their understanding of the term "modeling" and in how they address its teaching. This WG report summarizes the fi ndings and formulates recommendations on the inclusion of software modeling courses in future CS/SE curricula.

15 citations


Proceedings ArticleDOI
03 Jul 2012
TL;DR: This working group investigated how and when ( software) modeling is taught to help better understand the key issues in teaching (software) modeling and formulates recommendations on the inclusion of software modeling courses in future CS/SE curricula.
Abstract: Modeling is a key skill in software development. The ability to develop, manipulate and understand models for software is therefore an important learning objective in many CS/SE courses. In this working group, we investigated how and when (software) modeling is taught to help us better understand the key issues in teaching (software) modeling. Several shortcomings were found in common curricula, both in their understanding of the term \modeling" and in how they address its teaching. This WG report summarizes the findings and formulates recommendations on the inclusion of software modeling courses in future CS/SE curricula.

11 citations


References
More filters

Book
01 Jan 1994
TL;DR: The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns, which most experienced OOP designers will find out they've known about patterns all along.
Abstract: The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns. The nice thing is, most experienced OOP designers will find out they've known about patterns all along. It's just that they've never considered them as such, or tried to centralize the idea behind a given pattern so that it will be easily reusable.

22,753 citations


"If you're not modeling, you're just..." refers background in this paper

  • ...The next course, Engineering of Software Subsystems, is nicknamed the “Patterns Course” since it is based on [17]....

    [...]

  • ...The course covers most of the patterns in [17] using a problem-based learning (PBL) pedagogy....

    [...]


Book
02 Sep 2011
TL;DR: This research addresses the needs for software measures in object-orientation design through the development and implementation of a new suite of metrics for OO design, and suggests ways in which managers may use these metrics for process improvement.
Abstract: Given the central role that software development plays in the delivery and application of information technology, managers are increasingly focusing on process improvement in the software development area. This demand has spurred the provision of a number of new and/or improved approaches to software development, with perhaps the most prominent being object-orientation (OO). In addition, the focus on process improvement has increased the demand for software measures, or metrics with which to manage the process. The need for such metrics is particularly acute when an organization is adopting a new technology for which established practices have yet to be developed. This research addresses these needs through the development and implementation of a new suite of metrics for OO design. Metrics developed in previous research, while contributing to the field's understanding of software development processes, have generally been subject to serious criticisms, including the lack of a theoretical base. Following Wand and Weber (1989), the theoretical base chosen for the metrics was the ontology of Bunge (1977). Six design metrics are developed, and then analytically evaluated against Weyuker's (1988) proposed set of measurement principles. An automated data collection tool was then developed and implemented to collect an empirical sample of these metrics at two field sites in order to demonstrate their feasibility and suggest ways in which managers may use these metrics for process improvement. >

5,185 citations


"If you're not modeling, you're just..." refers methods in this paper

  • ...There are metric models of object-oriented software[18] that quantify the design principles we stress but, unfortunately, the tools we used so far measure from a code base and not a model of the system....

    [...]


Book
01 Jan 1997
TL;DR: This second edition of this book reflects the new developments in the field and new understanding of the important underpinnings of software architecture with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters.
Abstract: From the Book: Our goals for the first edition were threefold. First, we wanted to show through authentic case studies actual examples of software architectures solving real-world problems. Second, we wanted to establish and show the strong connection between an architecture and an organization's business goals. And third, we wanted to explain the importance of software architecture in achieving the quality goals for a system. Our goals for this second edition are the same, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters. Architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition. Architecture analysis has developed into a mature field with industrial-strength methods. This is reflected by a new chapter about the architecture tradeoff analysis method (ATAM). The ATAM has been adopted by industrial organizations as a technique for evaluating their software architectures. Architecture design has also had major developments since the first edition. The capturing of quality requirements, the achievement of those requirements through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve qualities are all captured in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and theattribute driven design (ADD) method, respectively. Architecture reconstruction or reverse engineering is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project, an analysis project, or to provide input into a decision process to determine what to use as a basis for reconstructing an existing system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context; in in this edition the topic merits its own chapter. Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected by all-new diagrams. But more important, an understanding of what kind of information to capture about an architecture, beyond what notation to use, has emerged. A new chapter covers architecture documentation. The understanding of the application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. The chapter reinforces the link between architecture and an organization's business goals, as product lines, based around a software architecture, can enable order-of-magnitude improvements in cost, quality, and time to market. In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend by updating the World Wide Web chapter, by using Web-based examples for the ATAM chapter and the chapter on building systems from components, by replacing the CORBA case study with one on Enterprise JavaBeans (EJB), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians. Finally, we have added a chapter that looks more closely at the financial aspects of architectures. There we introduce a method--the CBAM--for basing architectural decisions on economic criteria, in addition to the technical criteria that we had focused on previously. As in the first edition, we use the architecture business cycle as a unifying motif and all of the case studies are described in terms of the quality goals that motivated the system design and how the architecture for the system achieves those quality goals. In this edition, as in the first, we were very aware that our primary audience is practitioners, so we focus on presenting material that has been found useful in many industrial applications, as well as what we expect practice to be in the near future. We hope that you enjoy reading it at least as much as we enjoyed writing it. 0321154959P12162002

4,872 citations


Journal ArticleDOI
Abstract: This study examines the evidence for the effectiveness of active learning. It defines the common forms of active learning most relevant for engineering faculty and critically examines the core element of each method. It is found that there is broad but uneven support for the core elements of active, collaborative, cooperative and problem-based learning.

4,819 citations


"If you're not modeling, you're just..." refers background in this paper

  • ...There is ample evidence in the engineering education literature[13-15] that actively engaging the student results in the long-lasting learning that goes beyond what is needed for the next exam....

    [...]

  • ...A quantitative comparison with a non-PBL version of the course matches the research on problem-based learning[13]....

    [...]


Journal Article
TL;DR: This study reviews several of the most commonly used inductive teaching methods, including inquiry learning, problem-based learning, project-basedLearning, case-based teaching, discovery learning, and just-in-time teaching, and defines each method, highlights commonalities and specific differences, and reviews research on the effectiveness.
Abstract: Traditional engineering instruction is deductive, beginning with theories and progressing to the applications of those theories Alternative teaching approaches are more inductive Topics are introduced by presenting specific observations, case studies or problems, and theories are taught or the students are helped to discover them only after the need to know them has been established This study reviews several of the most commonly used inductive teaching methods, including inquiry learning, problem-based learning, project-based learning, case-based teaching, discovery learning, and just-in-time teaching The paper defines each method, highlights commonalities and specific differences, and reviews research on the effectiveness of the methods While the strength of the evidence varies from one method to another, inductive methods are consistently found to be at least equal to, and in general more effective than, traditional deductive methods for achieving a broad range of learning outcomes

1,673 citations


"If you're not modeling, you're just..." refers background in this paper

  • ...There is ample evidence in the engineering education literature[13-15] that actively engaging the student results in the long-lasting learning that goes beyond what is needed for the next exam....

    [...]