Session 12b1 Teaching Architectural Design in an ... - Semantic Scholar

Session 12b1 Teaching Architectural Design in an Undergraduate Software Engineering Curriculum J. Fernando Naveda Department of Software Engineering Rochester Institute of Technology Rochester, NY 14623-5608 US Abstract- In the fall of 1996, the Rochester Institute of Technology began admitting students to the nation’s first baccalaureate program in software engineering. One of the curriculum’s primary themes is software design, ranging from the very concrete (e.g., code, data structures and algorithms) to the more abstract (e.g., subsystems, architectural designs). At each of these levels we are able to address the variety of software quality issues that arise at different points in the software development process. This paper describes the structure of our introductory course in software architectures and our experience teaching it. We also speculate on how the course could evolve over time.

1

Introduction

Running on a quarter-based academic school year, RIT has a long history of innovation in career-oriented (coop) professional education. In 1996, we started admitting students to our baccalaureate program in software engineering. To the best of our knowledge, this was the first program of its kind in the United States. Throughout the curriculum we address software design at various levels of abstraction which range from the very concrete (such as code, data structures and algorithms) to the very abstract (such as classes, patterns, and architectural styles). Studying design at different abstraction levels allows us to understand software quality attributes at various stages in the software evolution process. This in turn allows us to explore how design decisions might affect a software system’s quality attributes. Design is one of our curriculum’s main themes. A theme spans across course boundaries and, depending on its nature, is given due attention as a topic within a series of courses or as a main subject of study within a course sequence (or both). Fundamental to software engineering, software design is a theme we think deserves much attention not only as a topic within a course sequence but also as the primary focus for a course sequence. In this paper we describe our experience building and delivering one such course in our curriculum’s design sequence: Principles of software architecture and design. Although design is addressed in at least two prerequisite courses, this course is the first in the sequence that deals specifically with architectural issues. Software architecture is a rare topic even at the master’s level. As a result we had to develop the course

from scratch. As interest in undergraduate software engineering curricula increases, it becomes more important that we share our experience in building and delivering courses in new topics. It is our hope that others benefit from what we’ve done. This paper is organized as follows: Section 2 describes our curriculum’s software design sequence. In Section 3 we discuss the course in detail. In Section 4 give an assessment of our experience teaching this course so far. We also discuss alternatives to both the lab and lecture components and give some final thoughts.

2

The Software Design Sequence

Four courses in computer science provide our students with basic knowledge on programming techniques, data structures, algorithms, and object oriented design. Java is the programming language of choice for the first three courses while C++ is the main programming vehicle for the fourth one. Our curriculum’s design sequence begins with an introductory course to software engineering where students work in teams of 4 to 6 towards a common project. Each team works in a simplified software life cycle that includes requirements, specification, design, testing, and implementation. The 10-week academic quarter puts severe constraints on what each team can effectively accomplish. Thus we put restrictions on document scope and size. It is in this course that students are exposed for the first time to the intricacies of making design decisions. Design topics include coupling and cohesion, and designing for maintenance and expandability. While the introductory course to software engineering addresses design issues, it does so in the context of an artifact the students build throughout the quarter. Thus, design at this stage is still a very concrete issue. The next course, engineering of software subsystems, deals with design from a more abstract point of view. Indeed, students learn about building software subsystems from abstract design patterns. The course focuses more on application of well-known design patterns than it does on concrete problems. Students who successfully finish this course are expected to understand what a design pattern is and how to apply design patterns in the larger context of a software system design.

0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 12b1-1

Session 12b1 Engineering of software subsystems is followed by a four-course sequence: Principles of software architecture and design, concurrent system design, distributed system design, and information system design. While principles of software architecture and design has been taught four times already, the remaining three courses are still in their planning stage or will be taught for the first time in the spring quarter of 1998. A complete description of our curriculum can be found in [1].

3

Course Structure

One of our curriculum’s landmarks is the formal lab concept. Unlike traditional computing courses where students are expected to work on projects in the form of homework assignments, formal lab courses have both a lecture and a required lab component. The lab meets for two hours once a week while the lecture meets for one hour three times a week. Lectures have an enrollment limit of 45 students while labs are limited to 15. As didactical as these courses can be, they represent a challenge to the course designer. First, the lab must help

academic programs, students who take this course have not yet gone through their first co-op. Thus building on real-life experience is not an option. We have to rely on academic background, a good textbook, a set of interesting lectures, and an interesting yet challenging lab component. The focus of the lectures is primarily on architectural styles and quality attributes discernable during the architectural stage. Table 3.1 gives a topical description of class material on a week by week basis. Note that the topics closely follow chapter titles taken from the course’s current textbook [2]. The reader is encouraged to obtain a copy of this textbook to get a better idea of the material covered. The core of the course’s material is presented during weeks 3 through 5. It is during this time that students start gaining an understanding of what an architectural design is and how it is different from, say, an object oriented design. Also, the relationship between quality attributes and architectures is explored here. During these first weeks we use the current lab project (project No. 1)

Table 3.1: Weekly lecture topics. Week 1

Topic Introduction: The architecture business cycle, software architectures.

4 5

Case study: A7-E, A case study in Utilizing Architectural Structures. Quality Attributes: Discernable during the architectural stage, at run time, and business attributes. Architectural Styles: A catalog of styles, their derivatives, and relationships among them.

6 7

The Software Architecture Analysis Method: Direct and indirect scenarios. Unit Operations: Design principles from which architectural styles can be derived.

8 9

Case study: The World Wide Web. Product lines: Reusing architectural assets within an Organization.

10

Case Study: CORBA

2 3

re-enforce important concepts presented in class. Second, the lab itself must present a challenge that students accept as an integral part of the course. Third, an interesting lab component coupled with an uninteresting lecture set may send the wrong message: the lectures, together with the exams, do not matter. And fourth, not all that is covered in lecture must be directly applicable in lab. Thus we developed the course in the context of these four observations. Sections 3.1 and 3.2 describe the lecture and lab components respectively. 3.1

Lecture Component

Typically, undergraduates lack the experience of working in real-life software systems for the most part. In addition, notwithstanding RIT’s reputation in co-op based

as an example to reflect on qualities and their relationship with architectural decisions made during the architectural stage. Note that it is not until week 6 that students learn about scenarios. Yet, project 1 is delivered on week 5 (see the lab weekly schedule on Table 3.2). Thus students do not know much about scenarios before presenting their first architectural design. There are various reasons for this. First, there is much material to cover and we only have ten weeks. Second, we thought that students could benefit from reflecting on their own work. That is, the second project’s architectural design must be presented using a scenario-based methodology while the first project, can be presented using whatever technique they choose. And third, we think that discussing a case study


Session 12b1 in class on week 2 serves as motivation for the course (note that week 2’s topic, the A7-E case study, could be

the team presents its design, it must show how it supports the quality factors it chose. The instructor decides if the

Table 3.2: Point breakdown and lab activity for a 5-week project. Week 1 [10 points] (Requirements analysis, exploration, and architectural design sketch) The primary goal of this lab is for each team to gain a clear understanding of the artifact they are about to implement. The team submits an architectural design sketch, which is presented and discussed in the next lab. Week 2 [20 points] (Architectural sketch discussion and final design submission) Each team discusses its architectural design sketch with the instructor and proceeds to firm up a final architectural design for submission. Week 3 [20 points] (Architectural design presentation and implementation) Each team presents its final architectural design and proceeds to its implementation. Week 4 [25 points] (User interface demonstration) Each team gives a brief demonstration of its artifact so far. While emphasis is on the user interface, it is expected that all teams be sufficiently close to finishing the project. Week 5 [55 points: 45 for lab; 10 for team evaluation] (Presentation, demonstration, and delivery) Each team presents its project during lab. A presentation includes an overview of the architectural design and its quality attributes, and a short demonstration.

exchanged with week 6’s topic, scenarios). We close the quarter with two case studies one on week 8 and another on week 10. Student reaction to case studies is very strong as they help relate lecture material with things with which they are familiar. Interestingly, the case studies are interchangeable. Thus one could pick another case study from the textbook or elsewhere and the result would be the same. Case studies are discussed in lecture on the assumption that students have read them before coming to class. 3.2

Lab Component

Although in lecture we discuss architectural styles in general, to be effective, the lab can only focus on one class of architectural styles. Furthermore, to home in on the relationship between quality attributes and architectural decisions, it is best to stick to a class of styles with which students are already familiar. Thus the lab’s main software deliverables are artifacts that are best understood in the context of sequential software architectures such as pipes and filters, layered systems, and virtual machines. We split the 10-week quarter into two 5-week team projects. A team consists of four to six students, depending on enrollment. Each project has about the same deliverables and counts the same towards the final grade (25% of the final grade each). The emphasis of both projects is on quality attributes and architectures. That is, students must select a set of three to five quality attributes prior to submitting an architectural design. Then, when

quality factors the team chose are discernable during the architectural stage, and if the proposed architecture supports these factors. Table 3.2 summarizes a typical 5week project, its deliverables and the point value for each submission. In Table 3.2 note that of the maximum 130 points awarded to a project, 40 (or 31% of the final grade) are explicitly weighed on the architectural design itself. Furthermore, of the 55 points allocated for the project’s final (Week 5) submission, only 10 of those points go towards functionality, while 25 points are allocated for the design’s in-lab presentation. Thus 65 (or 50% of the course’s final grade) out of a maximum of 130 points are weighed towards the artifact’s architecture itself. This was a deliberate decision, as the course’s emphasis is on architectural design. The low point allocation for behavior has the effect of focusing students on design matters rather than on flashy functions and complex user interfaces. On the other hand, the 25-point allocation towards the user interface (Week 4) helps to strike a good balance between architectural matters and visible parts of the project. Usability (a quality factor not discernable during the architectural stage) matters to the extent that a poor user interface can render a nicely designed system unusable. Teams are expected to apply their knowledge on design patterns and to use Java as the primary programming language. However, depending on the project, a mix of C (or C++) and Java is allowed to the extent that the team can convince the instructor that the


Session 12b1 language mix can benefit at least one of the quality factors chosen in Week 1. Documentation is kept to a minimum. The only documents that each team must submit are the architectural design sketch (Week 2) and the final architectural design (Week 3). Optionally they can resubmit their final architectural design document at the end of Week 5 in case major design changes were made. So far, no team has exercised this option. The final presentation must include a discussion of the artifact’s quality attributes, the architectural design, and explanations of how the design supports the quality factors. Typically, each team is given about 30 minutes to do their presentation and a short product demonstration. The emphasis of the presentation is on the architectural design. In the eventuality that the team may not be able to do even a short product demonstration while in lab, an off-lab time is agreed upon with the instructor for this part of the team’s submission. Typical projects we have given include a GUI-driven screen editor based on UNIX’s ed line editor and a UNIXbased archive tool. In the case of the editor project, the most likely architectural solution includes a virtual machine that interfaces with ed and a series of layers that manipulate data structures and general program state, and the graphical user interface. Typically, students choose performance (i.e., response time) as an important quality factor. Often they end up using UNIX’s named pipes to implement the interaction between their screen editor and UNIX’s ed. This choice is best implemented with a combination of Java and C or C++.

4

Lessons Learned and Future Course Versions

We’ve offered this course four times already. Course evaluations indicate that students perceive it as useful, interesting, and challenging. Interestingly enough, they think that the lecture component is quite valuable even if a portion of the material presented in class does not directly apply to either project. There is solid support for the case studies presented in class as well. A good textbook goes a long way towards making a course a pleasant experience. We are quite pleased with the textbook we chose and expect to keep it for a long time. It is both, easy to read and understand. Also, students claim that the case studies included in the book make for a nice mid-afternoon reading from time to time. The lab component enjoys much support as students feel that building a couple of non-trivial software artifacts is an important academic experience. There has been some criticism for lack of sample documents that students can use to guide their own document development. Java is a good language but from time to time we get complains that some of its advertised features do not quite

work or are hard to figure out. Also, an increasing number of students are using PCs for their development and when they port the code to the UNIX environment, one or two things do not work quite well. We are quite pleased with the course but continuously think about improvement. For example, we often think about compressing our discussion of the case study in Week 2 and making a short introduction to scenarios. This would prepare the students better for their first project presentation. What’s more, we have thought of the possibility of leaving all case studies for home reading. This would give us enough space to cover more technical topics in class. At this point, nevertheless, we are not planning to change the overall lecture structure. The lab’s two-project sequence is about right and we do not expect to change (to a one or three-project format, for example) it in the foreseeable future. We feel that two projects give students variety plus an opportunity to exercise what they learn under a different requirement set. In the larger scheme of things we hope that what we teach in this course will be used by our students well beyond the scope of their academic experience. We are aware that the full benefits of this course will only be realized after the rest of our program’s courses have been taught a few times and we have had a better feel for what is percolating downstream. Even more, students will go and come back from co-op a few more times and hopefully will give us a better idea of what, of all we are teaching them, works and what does not. As of today, all projects are developed in UNIX boxes and for UNIX boxes. For the near future we are planning a PC-lab that will support both Linux and Windows operating systems. This lab will give both faculty and students the opportunity to experiment with PC-based implementations. It will also give us the opportunity to emphasize platform-sensitive quality attributes such as portability in a more realistic environment. We expect to be reporting on our experiences as we go along.

5

References

[1] Naveda, J. F. and Lutz, M. J., “Crafting a Baccalaureate Program in Software Engineering”, Proceedings of the 10th Conference on Software Engineering Education, Virginia Beach VA, April 13 – 16, 1997, pp. 74-80. [2] Bass, L., Clements, P. and Kazman, R., “Software Architecture in Practice”, SEI Series in software Engineering, Addison Wesley, 1998.
