COMPUTER ENGINEERING DEPARTMENT
Course: CMPE 296G
Course Title: Software Architectures
Semester: Spring 2005
______
Instructor Information and Course Description
Instructor: Dr. M.E. Fayad, Office ENG 283I, , (408) 924-7364
Web page: http://www.engr.sjsu.edu/~fayad
Course Meeting Place/Time: Lecture: BBC 225, Wednesday 6:00 p.m. to 8:50 p.m. (18:00 to 20:50)
Office Hours: Tuesday: 3:30 p.m. – 5:30 p.m.
Thursday: 3:30 p.m. – 5:30 p.m.
Other times: Send an e-mail to schedule an appointment.
Course URL: http://www.engr.sjsu.edu/~fayad /current.courses/cmpe296g-spring05
Course Catalog DescriptionProvides in depth the concepts, principals, methods, and best practices in software architectures; emphasizes on team projects to architect domain-specific architectures, service-oriented architectures, product-line architectures, adaptive and generative architectures. Prerequisites: CmpE202, 3 unitsPrerequisites: CmpE202 (System Engineering), or instructor’s permission -- It is desirable the students have sound programming skills in C++ or Java and a sound first level exposure to data structures. Clear understanding of the concept of object oriented programming would help. Familiarity with C++ or Java is helpful but not mandatory. Students with excellent aptitude in the course but with little prior exposure to prerequisites may also take the course but they will have to put in substantial extra effort during the first one month or so.
Required Textbooks:
Must likely are a group of papers and/or one of the following books:
1. C. Hofmeister, R. Nord, D. Sonic. Applied Software Architecture. Addison-Wesley Object Technology Series, Addison-Wesley, October 1999, ISBN# 0201325713
2. Len Bass, Paul Clements & Rick Kazman; Software Architecture in Practice, 2nd edition, Addison-Wesley, 2003
3. Paul Clements, et.al., Evaluating Software Architectures: Methods and Case Studies , Addison Wesley, 2002
Support Text:
1. M. Fayad, D. Schmidt & R. Johnson. Implementing Application Frameworks: Object-Oriented Frameworks at Work, New York: John Wiley & Sons, September 1999, ISBN# 0-471-15012-1
2. M. Fayad and R. Johnson. Domain-Specific Application Frameworks: Experience by Industry, New York: John Wiley & Sons, October 1999 with a C.D.
3. B. Tekinerdogan. Synthesis-Based Software Architecture Design, Ph.D. Thesis, University of Twente, 2000
4. M. Johnson, R. Baxter, and T. Dahl. SanFrancisco Life Cycle Programming Techniques, Addison-Wesley, 2000 with a CD.
5. P. Monday, J. Carey, and M. Dangler SanFrancisco Component Framework: An Introduction, Addison-Wesley, 2000 with a CD.
6. M. Shaw and D. Garlan, Software Architecture-Perspectives on an Emerging Discipline, Prentice-Hall, Upper Saddle River, New Jersey, 1996.
Please note: More articles will be provided in the 16 weeks schedule below.
Student Learning Objectives:
By the end of the course, you should:
1. Have an ability to apply knowledge of several software architectures, such as product line architectures, service-oriented architectures
2. Have an ability to document effectively software architectures.
3. Have an ability to use the principles, methods, techniques, and skills of architecting any software systems.
4. Be capable of becoming a talented “software architects” with superior competence in building robust and adaptive software systems in extremely effective way.
Course Overview:
The OBJECTIVE of the course is to provide a sound technical exposure to the concepts, principles, methods, and best practices in software architecture and software design. The VISION of the course is to produce "software architects" with sound knowledge and superior competence in building robust, scalable, and reliable software intensive systems in an extremely effective way. They would have a clear appreciation of the role of abstraction, modeling, architecture, and design patterns in the development of a software product. They would be able to make optimal architectural choices and employ the most relevant methods, best practices, and technologies for architecting and implementing a software product, regardless of its complexity and scale.
Software architecture has become an area of intense research in the software engineering community. A number of architecture modeling notations and support tools, as well as new architectural styles, have emerged. The focus of architecture-based software development is shifted from lines-of-code to coarser-grained building blocks and their overall interconnection structure. Explicit focus on architecture has shown tremendous potential to improve the current state-of-the-art in software development and alleviate many of its problems.
This course will expose you to the concepts, principles, and state-of- the-art methods in software architectures, including domain-specific software architectures (DSSA), architectural styles, architecture description languages (ADL), software connectors, dynamism in architectures, and architecture-based testing and analysis. In the process of studying these concepts, we will make explicit the boundaries of the field and discuss its relationship to other areas of software engineering, specifically requirements, design (including object-oriented design and related notations, such as UML), and implementation. The course will also examine the practical applicability of architecture research, specifically its relationship to the work in software reuse and component interoperability platforms (such as CORBA, JavaBeans, and COM/DCOM). Homework assignments and an exam will be given to assess your understanding of important concepts, methods, languages, and tools. A project will give you an opportunity to study an aspect of architectures in more depth and "push the envelope" of architecture practice and research.
This course will treat the following topics in depth:
1. Software Architectures
Architecture-based software engineering research has yielded an impressive array of technologies and demonstrations over the past decade. Using an architecture-based approach, applications have been built which:
- Are understandable
- Are expected to evolve
- Exhibit remarkable flexibility
- Demonstrate significant reuse of off-the-shelf components
- Leverage experience from related applications in the same problem domain
- Are analyzable earlier in their development than ever before
- Are key milestones in software managerial and development processes.
Currently, there is relatively little guidance for software developers on how to develop software architectures. This course addresses several topics crucial to the state of the art and practice of software architecture. The course presents a complete reference on how to develop a good software architecture and provides guidelines for resolving key software architecture issues, such as evolving software architectures, leveraging existing investment in software architecture artifacts, representing architecture description languages, introducing formal models for software architectures, addressing architectural analysis techniques & development methods, transitioning from software architecture to coding and surveying architectural design tools and environments.
In addition, the course will include sections on: accessing of software architectures, testing and validating software architectures, improving software architecture quality, documenting software architectures, and many more.
2. Product-Line Architectures (PLAs)
Software product lines are emerging as a new and important software development paradigm. A Product-Line Architecture (PLA) is a design for a family of related applications, and its motivation is to simplify the design and maintenance of program families and to address the needs of highly customizable applications in an economical manner. Companies are realizing that the practice of building sets of related systems from common assets can yield remarkable improvements in productivity, time to market, product quality and customer satisfaction. But these gains are only a part of the picture; organizational, technical and management issues are other factors that should be considered. Although there are encouraging research experiences with PLAs and some guidelines exist to help in the development process, some issues about component-based development in PLAs are still under study. The goal of this course is to examine the foundational concepts underlying product lines and address the essential activities developers should consider to apply a PLA to a number of lines of products.
3. Service-Oriented Architectures (SOAs)
A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA
Course Format:
In first half of the semester I will cover the basic topics in the more traditional lecture format. There will be four structured exercises and a midterm test devoted to this part. The instructor, visitors, and students will jointly present some of the advanced topics in the second half. Students will work on a project of their choice during this period and submit a paper-length report (about 30 double-spaced pages including figures and references) by the last day of classes. Project presentations will be scheduled during the last and the final's weeks.
Grading (Tentative):
Midterm: 20%
Final Take Home 30%
Project (Team Reports): 40%
Short Essay: 10%
Your grade will be based on an overall curve.
Final Grades:
Letter grades will be assigned at the end of the course. Final grades will be based on a competitive curve. Graduate and undergraduate students are graded separately. Students will be informed of their standing at intervals throughout the course. Final grades are not negotiable. Unless there are mathematical errors, I will be unavailable to discuss final grades. Borderline cases will be considered with extreme care, and fair grades will be rendered.
Class Attendance:
Important: Class attendance is mandatory. If you have more than four unexcused absences, then you will be dropped from the class.
Due Dates:
Important: Late homework assignments, extra assignments, and projects are NOT ACCEPTABLE. In this case, the grade of any late homework assignments or any late projects will be assigned a “zero” mark. There will be no make up tests.
Group Projects:
The class will be divided into groups of 2-3 (three preferred) for team projects. Students will be responsible for forming groups. Students of the best 3 or 4 teams’ projects will give final presentations of their project work if asked. Grading criteria and project ideas will be posted in a project Web page.
On occasion, students take advantage of group work, letting other members perform the bulk of the work while they reap the benefits of a good grade and can spend more time on other classes. This happens only occasionally, but it will not be tolerated in this course. Two policies will help prevent this:
1. Twice during the semester, group members will be asked to fill out a detailed peer assessment for group members per project. This assessment will be based on four scales:
Assessment / Meaning / CorrespondenceZero / Doesn’t do anything / Get a Zero on the project
D / · 25% effort
· Attends 25% of the meetings
· Doesn’t participates in the discussion
· Does a poor job / Get a 25% of the
project’s grade
C / · 50% effort
· Attends 50% of the meetings
· Participates rarely in the discussion
· Does a so-so job / Get 50% of the
project’s grade
B / · 75% effort
· Attends 75% of the meetings
· Participates partially in the discussion
· Does an okay job / Get 75% of the
project’s grade
A / · 100% effort
· Attends all the meetings
· Participates effectively in the discussion
· Does an excellent job / Get 100% of the
project’s grade
Merely attending meetings won't be enough. Group members must be prepared for meetings, make good suggestions, perform their share of the work, and work well with other members.
The grading criteria for peer assessment is as follows:
a. Has the group member attended meetings?
b. Has the group member been prepared for group meetings? I.e. was he/she aware of assignment requirements, performed her/his duties, able to speak intelligently about the project, etc.?
c. Has the group member participated positively in meetings?
d. Has the group member performed their share of the work, as assigned?
e. Rate the quality of this group member's input to group discussions and design issues.
f. Has the group member been able to work well with others?
g. Rate the overall value of this group member to the project.
h. Rate the level of initiative this group member has exhibited in the project.
i. Other comments?
2. Groups experiencing problems with a student should let me know there's a problem. Do this early in the semester. My experience is that group members wait until it's too late to take action. My objective is to ensure that each group member has the opportunity to succeed. I will handle the situation and ensure there is no animosity while resolving the problem. Usually, a brief discussion will clear the matter up entirely and without further problems.
Policy on Cheating:
· A student or students involved in a cheating incident involving any non-exam instrument (homework, report, or lab project) will receive an F on that instrument, and will be reported to the judicial affairs office. Whether the report will carry a recommendation for disciplinary action will be left to my judgment.
· A student or students involved in a cheating incident on any quick test, the midterm exam or the final exam will receive an F in the course, and will be reported to the judicial affairs office with a recommendation for disciplinary action.
I will personally notify you of any such findings or actions. All such reports will also be brought to the attention of the computer engineering department office. You have certain rights of appeal, which may serve to exonerate you.
(see http://www.sjsu.edu/student_affairs/academicdishonestyrevisedpolicy.pdf)
Right to Privacy:
You will retain a right to privacy. I will not knowingly reveal your grades, student ID number, phone number, address or other private information to others, except within the limits of university policy. I will ask that you supply your first name, last name and last four digits of your SID on written homework or tests. The grader system requires that you supply the first five digits of your SID as a password. Grader permits you to access your own grade records and your standing in the class online, but no other person’s grade records or personal data.
Students with Disabilities:
Students with disabilities who would need some kind of accommodation should make that known to the instructor:
"If you need course adaptations or accommodations because of a disability, or if you have emergency medical information to share with me, or if you need to make special arrangements in case the building must be evacuated, please make an appointment with me as soon as possible, or see me during office hours."