CS 549b_Congese
Software Architecture
Course Outline: Spring 2006
University of Western Ontario
Course
Venue, Time and Dates:
|
IBM Training Centre |
|
Fridays, 10:00am - 3.30 pm 19 May
– 23 June 2006 |
Instructor
|
Email/Office |
Course website |
|
Nazim H. Madhavji |
nazim@csd.uwo.ca |
|
NEW or RECENT |
Date |
Description |
|
☛ |
9-08-06 |
Please check here for “overall” grades.: click here |
|
|
|
|
|
☛ |
15-06-06 |
Please download: (i) Quiz Answers and (ii) REFSQ’06_talk . Look under Drills, Projects, etc.: click here |
|
☛ |
13-06-06 |
Please download Project 1: click here |
|
☛ |
23-05-06 |
Download all lecture notes and Drill 2: click here |
|
☛ |
23-05-06 |
1. Dates for drills, projects, etc. have now been
added. 2. Please form groups of twos and fours (see the
table below). 3. Download new lecture notes: Creating
Architectures. 4. Download Drill 1. |
|
☛ |
12-05-06 |
Lecture notes and Resources: click here (Restricted
access) |
Back to the Top of the document
Course Description
This course focuses on
“software architectures”. A software architecture is an abstract representation
of a software system, filtering out what is traditionally considered design-
and implementation-level issues (such as: algorithm, design patterns, data
representation and coding) and highlighting such aspects as the system
structure, inter-relationships and interaction among these structures, and
other “run-time” properties of the system.
Whereas software requirements generally state the “what”
of a system, a software architecture states the “how” of a system. It sets
bounds for lower-level design of a system and gives a technical context to new software
requirements.
A
software architecture is widely recognized as a key, and an intellectual,
aspect of a software system. It is a primary means by which a software
organization can control and evolve a software system or product. Among the
resources required to create a high quality software architecture include:
software requirements; organizational context; domain and technical knowledge
and experience; existing system and its architecture (if any); appropriate
stakeholders; architecting notations, methods, techniques, tools and processes.
· The learning
objectives in this course are to become familiar with: the notion of
software architectures, different types of architectures, the role they play in
software systems and in software development, architecture creation and
evolution, architecture analysis, and documenting an architecture.
· Concepts presented in lectures are complemented by assignments,
class discussion and self-study.
Expectations
· This is not a
course where one writes thousands of lines of code in a programming language, characterized
typically by heroic efforts of getting the program to work in the days
approaching the project deadline. Rather, it is an intellectual course where
system-level decisions are represented in a high-level notation that together
form a software architecture. Such decisions require circumspection of a wide
variety of factors (technical, domain, business, socio-political and others)
that can affect the quality of a software system.
· In those attending
the course, it requires maturity, dedication, self-motivation, patience,
willingness to learn from diverse sources (not only lectures), and ability to
communicate and share with others.
· Lectures and class
time are primarily “triggers” for awareness of concepts in this subject and for
in-class interaction. To seriously understand this subject beyond class
material, students are expected to learn from identified sources, problem
solving and group work. In other words, much of “active learning” occurs
outside the classroom.
Prerequisites
· Software development experience (in any modern
programming language, such as C, C++, Java, etc.) at the level of final year
undergraduates at the university level.
· Experience with UML is useful for architecting.
UML will “not” be taught in the course.
· Knowledge and/or
experience in the areas of software requirements and software quality is
considered to be invaluable when conducting software architecture work.
For
those students who are not familiar with Requirements Engineering, recommend
that you read at least the following:
Requirements
Engineering, by Gerald Kotonya and Ian Sommerville, Wiley, 2001. (Especially
chapters 1, 3, 4, 6 and 8.)
Note: Students who have been admitted to this course
without the normal prerequisites may not have been exposed to some of the
background material expected for this course; it is the responsibility of these
students to gain familiarity with this material on their own. The instructor
will give advice.
Software Packages:
Students
“can” use any of the following or similar software packages during the
course. These tools are “not” provided,
however, and their availability is left to the individuals.
Textbooks:
Required Text book:
Software Architecture in Practice,
2nd edition
Len Bass, Paul Clements and Rick Kazman
Addison-Wesley, 2003
ISBN: 0-321-15495-9
Supplementary Text books:
Evaluating
Software Architecture: Methods and Case Studies
Paul
Clements, Rick Kazman, and Mark Klein
Addison
Wesley, 2004
ISBN:
9-780201-704822
Documenting
Software Architectures: Views and Beyond
Paul
Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little,
Robert Nord, Judith Stafford
Addison Wesley
Software Architecture, Perspectives on an emerging discipline
Mary Shaw and David Garlan
Prentice Hall, 1996
ISBN: 0-13-182957-2
The art of software architecture, Design methods and Techniques
Stephen T. Albin
Wiley, 2003
ISBN: 0-471-22886-9
Large-scale software architecture, A practical guide using UML
Jeff garland
Richard Anthony
Wiley, 2003
ISBN: 0-470-84849-9
Applied software architecture
Christine Hofmeister, Robert Nord and Dilip Soni
Addison-Wesley, 2000
ISBN: 0-201-32571-3
Software Engineering, An Object-oriented perspective
(Chapter 5 particularly)
Eric J. Braude
Wiley, 2001
ISBN:
0-471-32208-3
Software
Engineering – A Practitioner’s Approach, 5th edition
(Chapter 14 particularly)
Roger
Pressman: McGraw Hill.
Evaluation
· All material covered
or assigned in the course is examinable.
· The
instructor reserves the right to adjust (lower or raise) a student’s marks for
the tabulated components below based on his judgment of the student’s knowledge
and understanding of the subject matter during the term.
· Project logistics:
o Projects will be carried out in groups by default
but individuals can also propose to carry them out on their own upon
instructor’s approval.
o At the instructor’s discretion, a group member’s
marks in the project would be weighted by his/her participation and significance
levels, judged by the group peers, frequently during the
project – with the group maximum being the weight of one during any
single measure.
o It is the responsibility of each group member to:
1. act in a manner that would
avoid personal or other conflicts within the group,
2. contribute equitably to the project’s success in order to meet its goals.
o EXTREMELY IMPORTANT: In the event a group member is asked
to leave his or her group for reasons of discontentment on the part of any
member in the group, s/he will be required to carry out the project on his or
her own. Where this is not technically possible (e.g., other project roles and
persons are required) then the group member would have no choice but to
withdraw from the course. PLEASE note that there is nothing else that can be
done within the parameters of operation of this course.
· The grading criteria, as applied to each
evaluation component, will be described on the assignment as appropriate.
· Those
who miss the class quiz will receive zero marks for the quiz (exceptions only
as per the university policy).
· Late
submissions will not be accepted, so please be forewarned to commence tasks
upon assignment (exceptions only as per the university policy).
· If
for any reason any evaluation component tabulated below cannot be adhered to by
the instructors, the rest of the marks will be pro-rated.
|
Component |
% |
Critical dates or Duration |
Group size (max) |
|
Drill 1: Quality scenarios, Tactics Drill 2: Architecture 2 hour Quiz |
5 5 15 |
9th June. 9th June. 9th June. |
2 2 Individual. |
|
Project 1: creating an architecture |
30 |
23rd June. |
4 |
|
Project 2: evaluating an architecture |
15 |
23rd June. |
4 |
|
3 hour Exam* |
30 |
23rd June. |
Individual. |
|
Enrichment study (Optional) |
20 |
23rd June.** |
2 |
* If the exam score is less than, or equal to, 59% then the overall
course grade can be no more than 69% (C).
** Extension beyond this date to be
confirmed.
Lecture topics
The topic list is tentative. The actual topics will be dictated by the
dynamics of the class schedule.
|
Topic |
Chapter |
|
Course Overview & Preliminaries |
|
|
Introduction to software architectures |
Chapter 1 Chapter 2 |
|
Creating an architecture |
Chapter 4 Chapter 5 Chapter 7 |
|
Analyzing an architecture |
Chapter 11 Chapter 12 |
|
Documenting an architecture |
Chapter 9 |
|
Software product lines |
Chapter 14 |
|
Component-based development |
Chapter 18 |
|
Reconstructing a software architecture |
Chapter 10 |