-A A +A

CS2013-Strawman-SDF-Software Development Fundamentals (DEPRECATED)

13 posts / 0 new
Last post
sahami
CS2013-Strawman-SDF-Software Development Fundamentals (DEPRECATED)

The CS2013 Strawman Report comment period is now closed. Please see the CS2013 Ironman report for the latest CS2013 draft to comment on. Forum to comment on "SDF-Software Development Fundamentals" Knowledge Area in the CS2013 Strawman report. We ask that comments related to specific text in the report please specify the page number and line number(s) of the text being commented on. Line numbers are provided on the far left-hand side of the each page.

lkpresnell
SDF/Development Methods
field_vote: 
0
Your rating: None

In this section, on page 142, it would be helpful if "Avoiding common coding errors" was added as a topic. Yes, it is listed in the learning outcomes, but I think it is also an important topic area. For clarity, a minimum set of specific errors that should be included should be listed explicitly, such as integer errors, buffer overflow, memory leaks, input validation, poor encapsulation, etc.

adanyluk
Response
field_vote: 
0
Your rating: None

We've added the following bullet item in the topic area: Types of errors (syntax, logic, run-time)

A number of the specific errors you mention appear in the "Software Engineering" knowledge area.

blahedo
Constants, other less-fundamental programming concepts
field_vote: 
0
Your rating: None

This comment is sort of about SDF/Fundamental Programming Concepts (starts on p. 140), but it's more about the absence of any followup category. Two other SDF units, SDF/Algorithms and Design and SDF/Fundamental Data Structures, have a natural "next" category in AL/Fundamental Data Structures and Algorithms. But there seem to be a number of "intermediate" programming concepts that don't really have a home in any KU (that I could find).

These include, in no particular order,

  • constants (const, final)
  • operator overloading
  • copy constructors
  • enumerated types
  • typedefs
  • type casting

Some are present in only some languages, others are more broad, and I don't claim this is an exhaustive list. They aren't really specific to a paradigm, so they don't fit in the paradigm-flavoured KUs from the PL area, but many CS1/CS2 sequences will cover multiple of them, and it seems odd that they would not be part of the body of knowledge someplace.

adanyluk
Response
field_vote: 
0
Your rating: None

These are indeed important. As you've noted, however, some are language-specific. We've intended for the SDF knowledge area to be basic, fundamental, and language/paradigm agnostic. What we expect is that the topics in SDF will be (mostly) covered in an intro-type course along with concepts from the PL area that pertain to a specific language/paradigm.

blahedo
Program design/development techniques
field_vote: 
0
Your rating: None

I have a few topics I'd really like to see explicitly mentioned somewhere in Tier 1, and I'm not sure if they're currently there at all (and if they are, where). The two likely units for most of these are either SDF/Algorithms and Design (p 140) or SDF/Development methods (p 142).

  • Code refactoring, in the low-level CS1 sense of learning to see repeated code and deciding to abstract it into a function. Maybe this is what "abstraction" (p140, line 59) means? But that should be clearer. It's somewhat distinct from the inputs-to-outputs aspect of functions (line 91).
  • Reading code, tracing algorithms, working with pseudocode. All three are distinct, learned skills. Related to "Implementation of algorithms" (line 57) but really need to be mentioned explicitly someplace.
  • ADTs. They get mentioned in the outcomes (#10, line 75; implicitly also #11) but not in the topics? The idea of an ADT does seem to be hinted at in several of the "Fundamental design concepts" (Abstraction, Separation of behaviour and implementation) but the idea of an ADT is itself a concept that should be mentioned explicitly.
adanyluk
Response
field_vote: 
0
Your rating: None

Thanks for your suggestions.

We've added "refactoring" to SDF/Development Methods.

We've also added "program comprehension" to SDF/Development Methods.

blahedo
Implementation vs use
field_vote: 
0
Your rating: None

After reading and comparing SDF/Fundamental Data Structures (p141) to AL/Fundamental Data Structures and Algorithms (p38), and after reading the outcomes of each, it became somewhat clearer that you had effectively separated the use of the classic ADTs from their implementation, and that the SDF unit was more about their use (including choosing the right one), deferring implementation for later (possibly *much* later). I totally approve of drawing this distinction, and have used it effectively in my own classroom. Particularly for topics like "stacks, queues, priority queues, sets & maps" (line 117), this approach is comparatively new and enabled by the fact that modern language libraries include implementations for all of them, something that's only become true in the last ten to fifteen years.

All of which is to say that I love the separation but I'd like to see a little more explanation of this in the paragraph describing SDF/Fundamental Data Structures (lines 110-112), because it's not obvious from the text as written. A casual skim of the topics in this unit would seem to imply that it includes a lot more (about e.g. stacks, maps, references) than it actually does. When I first sat down to map our curriculum, I found this unit and thought it included a ton of material in, supposedly, 12 hours of lecture; it wasn't until I got a lot deeper in that I saw what was going on.

adanyluk
Response
field_vote: 
0
Your rating: None

For purposes of the CS2013 document, we've actually divided the data structures so that "simpler" linear ones appear in SDF and more complex (trees, graphs, etc) appear primarily in AL. With that said, we agree that it's completely reasonable to have students use ADTs early and then focus on their implementation later.

We have clarified the place of ADTs in the next draft of the SDF/Fundamental Data Structures section to indicate that we mean both use and implementation (again, with the instructor able to choose when to do each of these).

dcdl
Feedback on KA: SDF- Software Development Fundamentals
field_vote: 
0
Your rating: None

I have posted some comments that I believe apply to all KAs within the CS2013 Strawman Report-Chapters 1-5 thread. I would like to make reference to those comments here since they apply to all KAs.

The comments are posted under the following subjects:
First of All: Thank You.
Matching of Topics and Learning Outcomes for Core-Tier-1 and 2.
Unique Labeling or Numbering of all Topics and Learning Outcomes.
Improved Correspondence between Learning Outcomes and Topics.
Consistent Labeling for Levels of Understanding.
On the Importance of the Learning Outcomes in Core-Tier1 and 2.

Comments for this KA:

Page 140, Line 88: I would separate this topic into 'Assignments and side-effects' and 'Expressions without and with side-effects.'

Page 140, Line 113: I would very much like to see in this section topics on Abstract Data Types or a clearer distinction between ADTs and their respective implementation Data Structures. I believe that before introducing the data structures in lines 114-120 it is due to describe ADTs from an abstract perspective first. The differentiation between ADTs and their implementation using Data Structures does not seem to be stressed enough. I cannot observe the same as pointed out by a previous poster that between this page (140) and page 38 the document makes a clear distinction between ADTs and their implementations. In fact, the acronym ADT does not appear in the whole document and the term 'abstract data structure' does not appear neither. The only place where this seems to show is line 117 (page 141) but this is interleaved with concrete DS such as arrays.

adanyluk
Response
field_vote: 
0
Your rating: None

Page 140, Line 88: I would separate this topic into 'Assignments and side-effects' and 'Expressions without and with side-effects.'

>> We've left the line as is. While we appreciate your point, it goes beyond the scope of what we intended (which was simply that students learn the terminology and be able to write simple expressions and assignment statements).

Page 140, Line 113: I would very much like to see in this section topics on Abstract Data Types or a clearer distinction between ADTs and their respective implementation Data Structures. I believe that before introducing the data structures in lines 114-120 it is due to describe ADTs from an abstract perspective first. The differentiation between ADTs and their implementation using Data Structures does not seem to be stressed enough. I cannot observe the same as pointed out by a previous poster that between this page (140) and page 38 the document makes a clear distinction between ADTs and their implementations. In fact, the acronym ADT does not appear in the whole document and the term 'abstract data structure' does not appear neither. The only place where this seems to show is line 117 (page 141) but this is interleaved with concrete DS such as arrays.

>> This has been a theme in several comments. We believe we have now clarified the distinction between ADT use and implementation in the next draft of the document.

sahami
Feedback from ACM Education Council meeting
field_vote: 
0
Your rating: None

[Below is the feedback captured at the ACM Education Council meeting breakout session]

Could consider SDF + X making for a good minor in CS. This might be a good model for “Computational X”

Where does persistence of data structures belong? Does it belong in SDF/Fundamental Data Structures?

Line 57: “Implementation of algorithms” could be interpreted broadly. Should be tightened.

Line 68: remove “pseudocode or” (And you can't debug pseudocode well)

Line 71: [Evaluation] seems too strong a level for understanding. Perhaps just rephrase the learning outcome. Too many instructors will reinterpret this to say that students should know when a recursive solution is inappropriate.

Line 98: “use each of the primitive data types” seems too strong. Remove “each of”. (This depends on language. For example, students don't need to use all the primitive data types of C++).

Need to be explicit that all of this (SDF) doesn’t need to covered in the first year.

Line 114: Arrays or indexed linear structure (e.g., ArrayList, vector). Have some generalized notion of array here.

Line 119: Be more specific about: linked lists, tree, and graphs
(Mehran: perhaps cross-reference AL/Fundamental Data Structures and Algorithms)

SDF/Fundamental Data Structures – graphs need to be in Learning Outcomes as well.

SDF/Development Methods – should get rid of named IDEs (line 162)
Add something about sources of errors – want students to know what are some of the common sources of errors

Copy edits:
"In order to effectively use computers to solve problems, students..." should be changed to: "In order to use computers to solve problems effectively, students..."

Line 152: "the production of quality software" should be "the production of high-quality software"

adanyluk
Response
field_vote: 
0
Your rating: None

Below are item-by-item responses:

Where does persistence of data structures belong? Does it belong in SDF/Fundamental Data Structures?

>> We've added files (more specifically, file I/O) to SDF/Fundamental Programming Concepts to capture persistence.

Line 57: “Implementation of algorithms” could be interpreted broadly. Should be tightened.

>> We've deleted the "topic", agreeing that it is vague. The learning outcomes are much more clear.

Line 68: remove “pseudocode or” (And you can't debug pseudocode well)

>> done!

Line 71: [Evaluation] seems too strong a level for understanding. Perhaps just rephrase the learning outcome. Too many instructors will reinterpret this to say that students should know when a recursive solution is inappropriate.

>> We've modified the learning outcome. It will now be as follows:
determine whether a recursive or iterative solution is most appropriate for a given problem

Line 98: “use each of the primitive data types” seems too strong. Remove “each of”. (This depends on language. For example, students don't need to use all the primitive data types of C++).

>> done

Need to be explicit that all of this (SDF) doesn’t need to covered in the first year.

>> added "will typically be" language to the preamble for this knowledge area

Line 114: Arrays or indexed linear structure (e.g., ArrayList, vector). Have some generalized notion of array here.

>> Here we felt that it was best to leave the bullet item as is

Line 119: Be more specific about: linked lists, tree, and graphs
(Mehran: perhaps cross-reference AL/Fundamental Data Structures and Algorithms)

>> We're now more clear that "simple linked structures" means "linked lists" here. Trees and graphs are covered in the Algorithms and Complexity (AL) knowledge unit. (Faculty can obviously choose to still do those in the first year.)

SDF/Fundamental Data Structures – graphs need to be in Learning Outcomes as well.

>> See previous comment.

SDF/Development Methods – should get rid of named IDEs (line 162)

>> Done

Add something about sources of errors – want students to know what are some of the common sources of errors

>> Done

Copy edits:
"In order to effectively use computers to solve problems, students..." should be changed to: "In order to use computers to solve problems effectively, students..."

Line 152: "the production of quality software" should be "the production of high-quality software"

>> both done

Log in or register to post comments