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, m.fayad@sjsu.edu, (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:
Other times:
Tuesday:
3:30 p.m. – 5:30 p.m.
Thursday: 3:30 p.m. – 5:30 p.m.
Send an e-mail to schedule an appointment.
Course URL: http://www.engr.sjsu.edu/~fayad /current.courses/cmpe296g-spring05
Course Catalog Description
Provides 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 units
Prerequisites: 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
1 of 7
COMPUTER ENGINEERING DEPARTMENT
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.
B. Tekinerdogan. Synthesis-Based Software Architecture Design, Ph.D. Thesis, University
of Twente, 2000
M. Johnson, R. Baxter, and T. Dahl. SanFrancisco Life Cycle Programming Techniques,
Addison-Wesley, 2000 with a CD.
P. Monday, J. Carey, and M. Dangler SanFrancisco Component Framework: An
Introduction, Addison-Wesley, 2000 with a CD.
M. Shaw and D. Garlan, Software Architecture-Perspectives on an Emerging Discipline,
Prentice-Hall, Upper Saddle River, New Jersey, 1996.
3.
4.
5.
6.
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-theart in software development and alleviate many of its problems.
2 of 7
COMPUTER ENGINEERING DEPARTMENT
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 ProductLine 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
3 of 7
COMPUTER ENGINEERING DEPARTMENT
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:
Final Take Home
Project (Team Reports):
Short Essay:
20%
30%
40%
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.
4 of 7
COMPUTER ENGINEERING DEPARTMENT
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
Zero
Doesn’t do anything
D
 25% effort
 Attends 25% of the meetings
 Doesn’t participates in the discussion
 Does a poor job
C
 50% effort
 Attends 50% of the meetings
 Participates rarely in the discussion
 Does a so-so job
B
 75% effort
 Attends 75% of the meetings
 Participates partially in the discussion
 Does an okay job
A
 100% effort
 Attends all the meetings
 Participates effectively in the
discussion
 Does an excellent job
Correspondence
Get a Zero on the project
Get a 25% of the
project’s grade
Get 50% of the
project’s grade
Get 75% of the
project’s grade
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.
5 of 7
COMPUTER ENGINEERING DEPARTMENT
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:
6 of 7
COMPUTER ENGINEERING DEPARTMENT
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."
Hand In:
All homework assignments and projects need to be typed and handed in as hardcopies and
electronically. You also need to demonstrate Projects to the instructor. Hand-written assignments
and projects are not acceptable and we receive a “zero” mark. Check submission guidelines.
An “F” grade will be assigned if an individual misses three or more assignments out of five.
Class Webpage: http://www.engr.sjsu.edu/~fayad /current.courses/cmpe296g-spring05
contains the syllabus, some of the homework and lecture notes, and occasional notices.
7 of 7