Download Syllabus Schedule for Software Design | CSE 335 and more Study notes Computer Science in PDF only on Docsity!
Instructor:
Dr. Alex X. Liu, Office Hours: Tuesday & Thursday 2:00 PM - 3:00 PM, or by appointment Office: 2132 Engineering Bldg Course homepage: http://www.cse.msu.edu/~alexliu/courses/335Spring2012/ TA: Syeda Momina Tabish ( [email protected] ) Office hours: Monday and Wednesday 5:00-6:00 PM; Friday 12:00 - 1:00 PM or by appointment. Extra office hours: 6:00PM-9:00PM on 2/6, 2/12, 2/16, 3/11, 3/21, 3/25, 4/8, 4/22, 4/25. Location: 3353 Engineering (Simpsons Lab). Eric Norige ( [email protected] ) Regular office hours: Tuesday and Thursday 10:00 AM - 11:00 PM, Friday 4:30-5:30 PM or by appointment. Extra office hours: 6:00PM-9:00PM on 1/22, 2/5, 2/19, 3/4, 3/18, 3/20, 4/1, 4/15, 4/24. Location: 3353 Engineering (Simpsons Lab). Prerequisites: CSE 232 (fluency in the C++ programming language). CSE 260 (discrete structures). Background and goals: This course will introduce students to the development of large software products, libraries, and product families with emphasis on design concerns that dominate the development of such software. These concerns include reliability, reusability, maintainability, and ease of extension and contraction. Students will learn how to use object-oriented design techniques to address these concerns. The course emphasizes explicit modeling and critical analysis of designs prior to implementation. Students will learn heuristic methods to design for integration and changes in requirements. Students will also learn the fundamentals of software specification and techniques for designing software to meet its specification. This course focuses on implementation techniques, analysis and design heuristics, and best practices that have proved useful in making the software-development process rigorous, systematic, repeatable, and manageable. Students will be introduced to current methods, which they will apply to programming and design projects. Finally, this course is primarily about design , which is very difficult to learn by reading a book or cramming for a test. Design problems involve choices and tradeoffs, and often there is no single "right" answer. The instructor's role in such a course is to set up an environment that will force students to confront and appreciate difficult design issues and to provide critical and continual feedback to students on their choices. It is the student's responsibility to actively participate in this environment and to reflect and respond to the issues that are discussed. To achieve these goals, we will supplement the lectures and required readings with in-class collaborative exercises and materials on heuristics for problem solving. Topics to be covered include:
CSE 335 Syllabus for Fall 2009 http://www.cse.msu.edu/~alexliu/courses/335Spring2012/Syllabus.html
1 of 4 1/10/2012 11:39 AM
Design principles, specifically: abstraction, anticipation of change, generality, incrementality, modularity,
reusability, and separation of concerns Design methods, patterns, and heuristics composites, strategies, visitors, observers, and adapters role-collaboration design Maintenance issues Modeling notations and methods, specifically UML Software architecture Specification and documentation Required textbooks: Object-Oriented Modeling and Design with UML (Second Edition) by Blaha and Rumbaugh, Pearson/Prentice-Hall, 2005. Design Patterns: Elements of Reusable Object-oriented Software by Gamma, Helm, Johnson, and Vlissides, Addison Wesley, 1995. Grading: Your grade will be determined as follows: Exam 1 10% Exam 2 10% Exam 3 10% Project 1 10% Project 2 10% Project 3 10% Mini-Project 1 5% Mini-Project 2 5% Mini-Project 3 5% Mini-Project 4 5% Mini-Project 5 5% Mini-Project 6 5% Attendance 10% Grading Policy
- All grades become final two days after the grade is issued. There will be no exceptions. If a student wishes to challenge any exam grade, he or she must do so in writing, with a concise explanation for why his or her misgraded answer is correct. This explanation should be submitted to the TAs.
Regrading request will cause the entire exam of the student to be regraded, and thereby the overall grade of the student may increase or decrease.
- ALL questions regarding exam and project grades should go to the TAs. If the problem cannot be resolved after consultation with the TAs, the TAs will forward a summary of the problem to the instructor (with an e-mail carbon-copy the student).
Attendance Policy : Attendence is REQUIRED. Your attendance will be monitored and graded based on random roll calls. Examinations: There will be three examinations during the term. There will be no final exam per se. The dates and times for these exams are as follows:
CSE 335 Syllabus for Fall 2009 http://www.cse.msu.edu/~alexliu/courses/335Spring2012/Syllabus.html
2 of 4 1/10/2012 11:39 AM
answer from the TAs, then email the instructor briefly explaining when you email the TA, what's his reply, and why
you are not satisfactory. I tend to defer reading email until the end of a day, but you should be able to receive my reply within 24 hours. Integrity and ethics: The policy of the university on integrity of scholarship and grades (pages 49-50, Academic Programs, 1993) will be followed. Implicit in handing in homework, papers, and exams is that they represent the student's own work. Any exceptions should be pre-approved by the instructor and explicitly noted. Note that for any material that you can find, especially if it is available on the web, I can find it too. Students who plagiarize will receive a 0.0 for the course or 0.0 for the assignment at the instructor's discretion. All students are expected to be responsible users of the computer system provided for this course. Account usage guidelines published by the Department of Computer Science and Engineering are available at http://www.cse.msu.edu/facility/policy.html. In addition, students are expected to adhere to MSU's policy on "Good Citizenship in 'Cyberspace'" (Section IV, p.85 of Spartan Life). Article 2.3.5 of the Academic Freedom Report (AFR) for students at Michigan State University states: "The student's behavior in the classroom shall be conducive to the teaching and learning process for all concerned." Article 2.3.10 of the AFR states that "The student has a right to scholarly relationships with faculty based on mutual trust and civility." General Student Regulation 5.02 states: "No student shall... interfere with the functions and services of the University (for example, but not limited to, classes.. .) such that the function or service is obstructed or disrupted. Students whose conduct adversely affects the learning environment in this classroom may be subject to disciplinary action through the Student Faculty Judiciary process.
CSE 335 Syllabus for Fall 2009 http://www.cse.msu.edu/~alexliu/courses/335Spring2012/Syllabus.html
4 of 4 1/10/2012 11:39 AM
Date Topic Announcements and notes 01/10 TU Introduction 1. Do homework 1. 01/ TH Class Inheritance
- Do homework 2. To access HW
directory, please login to your CSE account. Then type the following commands: cd .. cd cse335/AlexLiu/HW 01/17 TU Polymorphism Mini-Project 1 on Polymorphism is out. Due at 11:59 PM on 1/22. 01/ TH UML Basic Class Modeling Rumbaugh book chaper 3 & 4 01/24 TU Composite Pattern
- Gamma book "Composite" chapter.
- Do homework 3.
01/ TH Visitor Pattern
- Gamma book "Visitor" chapter.
- Project 1 is out.
01/31 TU Case Study: Composite Pattern + Visitor Pattern 02/ TH Review Session for Exam 1 02/07 TU Exam 1 at EB 2243 Extra Office Hours for Exam 1: Eric Norige ([email protected]): 6:00PM-9:00PM on Feburary 5th Syeda Momina Tabish ([email protected]): 6:00PM-9:00PM on Feburary 6th 02/ TH Exam 1 Debriefing 02/14 TU Make and Makefile 02/ TH Abstract Factory Pattern + Exam 1 Debriefing
- Gamma book "Abstract Factory"
chapter.
- Mini-Project 2 on Abstract Factory
Pattern is out. Due at 11:59 PM on 2/26. 02/21 TU Builder Pattern
- Gamma book "Builder" chapter.
- Mini-Project 3 on Builder Pattern is out.
Due at 11:59 PM on 3/4. 02/ TH Adaptor Pattern
- Gamma book "Adaptor" chapter.
- Do homework 4.
- Mini-Project 4 on Adapter Pattern is out.
Due at 11:59 PM on 3/11. 02/28 TU Observer Pattern
- Gamma book "Observer" chapter.
- Do homework 5.
- Project 2 is out.
CSE 335 Spring 2011 http://www.cse.msu.edu/~alexliu/courses/335Spring2012/Lectures.html
1 of 3 1/10/2012 11:39 AM
Acknowledgement: The slides contain material from the books "Disign Patterns" and "Object-Oriented Modeling and Design with UML", R. E. K. Stirewalt's slides, and some other resources.
CSE 335 Spring 2011 http://www.cse.msu.edu/~alexliu/courses/335Spring2012/Lectures.html
3 of 3 1/10/2012 11:39 AM
1
CSE 335: Software Design
Dr. Alex X. Liu
http://www.cse.msu.edu/~alexliu
2243 Engineering Building
Department of Computer Science and Engineering
Michigan State University
Reasons to take CSE 335
Many reasons to take CSE 335
─ E.g., it is required!
Help you to become a master programmer and designer
─ From writing small programs that simply works to design large systems
Help you to succeed in job interviews
Help you to succeed in job interviews
─ e.g, Google.
You are very fortunate!
─ Very few computer science departments offer a course on design patterns
How to learn this course well?
1. Before class:
─ Study slides or corresponding chapters. ─ Bring your questions to the class.
2. During class:
─ Listen to lectures carefully. ─ ASK any questions at any time.
3 After class:
3. After class:
─ Review lectures in team. ─ Do homework in team. ─ Do mini-projects in team. ─ Do projects in team.
Strictly follow the above 3 steps. I guarantee that you will enjoy
and learn this course well.
Science vs. Engineering
Science is on discovery
Engineering is on design:
─ The application of scientific principles and methods to the construction of useful structures & machines
Programming vs. Engineering
Programming ─ Small project ─ You ─ Build what you want ─ One product ─ Few sequential changes ─ Short-lived ─ Cheap ─ Small consequences E i i
Engineering ─ Huge project ─ Teams ─ Build what they want ─ Family of products ─ Many Parallel changes ─ Long-lived ─ Costly ─ Large Consequences
Software Engineering
Software engineering is a special type of engineering
─ Software is extremely complex ─ Software construction is human-intensive ─ Software is intangible and invisible ─ Software is constantly subject to pressure for change ─ Software needs to conform to arbitrary interfaces and contexts
● E.g., business rules and processes vary dramatically from business to business ● E.g., existing databases of information.
3
Economic and Management Aspects
Software production = development + maintenance (evolution)
Maintenance costs > 60% of all development costs
Quicker development is not always preferable
─ higher up-front costs may defray downstream costs poorly designed/implemented software is a critical cost factor
─ poorly designed/implemented software is a critical cost factor
Relative Costs of Fixing Software Faults
Requirements Specification Planning Design Implementation Integration Maintenance
Hardware Failure Curve
R
ate
“infant mortality”
Wears out
Time
Failure R
Ideal Software Failure Curve
R
ate
(^) continues at same rate until software is retired
Time
Failure R
Actual Software Failure Curve
u
re Rate changes
actual curve
Time
Failu
(^) g
ideal curve
How to become a software design master?
Learning to develop good software
is similar to
learning to play good chess
4
To become a chess master
First, learn the rules
─ e.g., names of pieces, legal movements, captures, board geometry, etc.
Second, learn the principles
─ e.g., relative value of certain pieces, power of a threat, etc. ─ But principles are abstract. How to apply them in practice?
Third, learn the patterns by studying games of other masters
─ These games have certain patterns that must be understood, memorized, and applied repeatedly until they become the second nature.
To become a software design master
First, learn the rules
─ e.g., programming languages, data structures, etc.
Second, learn the principles
─ e.g., software engineering principles such as separation of concerns, etc. ─ But principles are abstract. How to apply them in practice?
Third, learn the patterns by studying designs of other masters
─ These designs have certain patterns that must be understood, memorized, and applied repeatedly until they become second nature.
Software Engineering Principles
Rigor and formality
Separation of concerns
Modularity
Ab t ti
Abstraction
Anticipation of change
Generality
Incrementality
Rigor and formality
Software development is a creative design process.
─ But creativity implies informality, imprecision, and inaccuracy
Rigor and formality are necessary:
─ to improve quality and assurance of creative results ─ to ensure accuracy in defining and understanding problems
Rigor and formality help to improve reliability and verifiability
Evident in:
─ Design notations, requirements, specifications, process definitions
Separation of concerns
We cannot deal with all aspects of a problem simultaneously
To conquer complexity, we need to separate issues and tasks
─ Separate functionality from efficiency ─ Separate requirements specification from design ─ Separate responsibilities
Di id &
Divide & conquer
Today’s applications involve interoperability of
─ Client/Server, Legacy system, COTS (Commercial Off-The-Shelf), databases, etc. ─ Multiple programming languages (C, C++, Java, etc.) ─ Heterogeneous hardware/OS platforms
Separation of concerns is critical!
Modularity
A complex system may be divided into simpler pieces called
modules
A system that is composed of modules is called modular
Supports separation of concerns
─ when dealing with a module we can ignore details of other modules
Three goals with modularity
bili b k bl i ll b bl (di id )
─ Decomposability: break problem into small sub-problems (divide&conquer) ─ Composability: construct solution from sub-solutions ─ Understandability: understand system by understanding sub-systems
Two essential properties
─ Cohesion: degree to which parts of a module are related (within a module) ─ Coupling: amount of interdependence between modules (among modules)
6
Example of Bad Design
class Employee{ public: string firstName; string lastName; Date hiring_date; short department; };
class Manager{ public: Employee emp; list<Employee*> group; short level; };
Why this design is bad?
─ Inconsistent with domain knowledge: a manager is always an employee (Domain knowledge is stable over time.) ─ A manager may have another manager in their group ─ What if you want to add another role “vice president” above manager? ─ What if you want to print out the name of every employee?
Example of Good Design
class Employee{ public: string firstName; string lastName; Date hiring_date; short department; };
class Manager: public Employee{ public: list<Employee*> group; short level; };
Recall the “abstraction” principle
Recall the “separation of concerns” principle
Recall the “anticipation of change” principle
Recall the “generality” principle
Recall the “incrementality” principle
Recall the “modularity” principle
Assignment
Do Homework 1
─ http://www.cse.msu.edu/~alexliu/courses/335Spring2011/Homework.html
CSE 335 Homework 1
Objectives: Review fundamentals and design skills from CSE 231 and CSE 232. Specifically:
1. Construction of Makefiles to rebuild executables from source code.
2. Use of functional decomposition to design a complex function by inventing new, simpler
functions, which can be used together to compute the complex function in a straightforward
manner, thereby mitigating the complexity.
Description: The files ˜cse335/AlexLiu/HW/HW01/hw01.* constitute a program that gath-
ers statistics on web-server usage by processing log files, which are created by the server. The im-
plementation is complete, with the exception of an undefined function in the file hw01.datatime.cpp,
and the HW01 directory contains several files with sample data.
Tasks:
1. Look at the source files to tease out the compilation dependencies, and then construct a
Makefile that describes how to build an executable from these files. Call this executable
file logstats, and write the Makefile so that logstats will be made when the user types
make at the Unix command prompt. Note: This program will not link until you complete
task 2 below.
2. The link error in task 1 results from a missing function, called convertLocalTimeToGMT,
which converts a date–time representation, called local time , into a world-wide standard date–
time representation called Greenwich Mean Time (GMT). The local time represents the wall-
clock date/time as measured in some locale plus a (positive or negative) offset , which is used
to convert the local time into the GMT representation.
You must design and implement this missing function. The logic involved in coverting local
time into GMT is fairly complex. For example, adding or subtracting the offset to the hour
component of the local time might affect the day, the month, and even the year. Moreover,
your logic must correctly account for leap years. To mitigate this complexity, we ask that
you do a pencil-and-paper design before writing any code. You should use the principle of
functional abstraction to design this function and reason about its correctness. We expect you
to use the helper functions:
• thirtyOneDayMonth,
• thirtyDayMonth, and
• leapYear
which are provided in the file hw01.datetime.cpp
As a guideline, none of your functions should exceed 20 lines in length, including the function
convertLocalTimeToGMT. Moreover, each function should be cohesive , in the sense that it
solves only one conceptual problem, and it must be appropriately named and commented. When
the instructor originally implemented this exercise, he came up with 5 functions, in addition to the
utilities already provided in the sample files.
