CSP 1-8, CIS 8030
PRIMARY TEXT AND MATERIALS:
Textbook: Len Bass,
Paul Clements, Rick Kazman, Software architecture in Practice, 2nd
Edition, Addison Wesley Professional, 2003.
Required case packet: IMPORTANT SO PLEASE READ THIS! ===>
The packet of cases is available exclusively from The Print Shop, #6 Decatur Street, downtown near Five Points. The cost is largely that of royalties charged on the cases from Harvard and other sources.
CATALOG DESCRIPTION:
This course will explore the concepts, principles, and state-of- the-art
methods in enterprise architectures, including architectural styles,
architecture description languages (ADL), software connectors, dynamism in
architectures, and architecture-based testing and analysis. The course will help
understand the role of architecture in software engineering, specifically during
requirements analysis, design (including object-oriented design and related
notations, such as UML), and implementation. The course will also cover
practical applicability of architectures in software reuse and component
interoperability platforms (such as CORBA, Enterprise JavaBeans, COM/DCOM, and
.NET).
DETAILED COURSE DESCRIPTION:
A enterprise architecture is an abstract view of a system which is distinct from the details of implementation, algorithms, and data. Enterprise architecture has become an area of major interest in the software development community. A number of architecture modeling notations and support tools, as well as new architectural styles, have emerged in the recent years. Architecture-based software development helps shift focus to coarser-grained building blocks and their interconnections rather than focusing on the code level. In short it is an Enterprise-level view of the portfolio of systems elements with a goal toward greater integration and more efficient deployment and exploitation of those elements.
Another objective of this course is participants to understand the issues and decisions that must be made when managing an ERP project. Every project is different; there are different organizational contexts, infrastructures and strategies. Even so systematic approaches are believed to improve the likelihood of ERP project implementation success. This is because methods draw on standards and previous learning and require the reuse of resources and competencies. The problem is that no single method is universal; no method fits all settings. A methods engineering approach is one where using high-level analysis and assessment modeling techniques a development team in which the knowledge management development team analyzes the business situation and, drawing from an inventory of method pieces, assembles methods technique fragments that together comprise a customer/engagement specific methodology. This course describes general lifecycle and project management models for ERP systems. The issues are discussed and illustrated via academic and industry cases.
Accordingly, this course gives explicit consideration to the notion of enterprise architecture in general terms and though examination of an instance of well developed architectures in the form of ERP systems. The course will provide a generalized understanding of the fundamentals of software architectural themes and concepts. Also, methods, formalisms and tools necessary for transferring architectural decisions to designs and implementations will be covered.
DETAILED COURSE OBJECTIVES
At the end of the semester, the student will:
·
differentiate the relationships
between system qualities and enterprise architectures
·
recognize software architectural
patterns and their relationship to system qualities
·
analyze enterprise architecture
evaluation
·
assess attribute-driven design
within the organization
·
understand and recognize
when/where architectural reuse may be employed
·
postulate the future of enterprise
architectures
·
understand and differentiate
between a stakeholder- and view-based approach to documenting enterprise
architectures
·
know how to implement formal and
informal notations (including the Unified Modeling Language [UML] in
representing elements and relations in a view
·
develop a service-oriented
architecture
·
understand how to utilize the role
of architecture in achieving agility
COURSE ASSIGNMENTS AND EXAMS:
Name
|
Description
|
|
Mid Term |
Assesses the understanding of fundamental enterprise
architecture themes and concepts. |
|
Final Exam |
Tests understanding of issues in transferring
architectural decisions to designs and implementations. The focus is on
research and commercial off-the-shelf (OTS) tools, techniques, and
interoperability platforms covered in the latter part of the course. |
|
Class project |
In-depth treatment of a topic in enterprise architectures. The project will
be conducted by teams of four students. Smaller or larger teams, as well as
individual projects will be allowed under special circumstances Depending on
the nature of the project, it may involve implementation. Possible project
ideas will be discussed in class in Week 5.
-
Proposal 3%
-
Progress report 6%
-
Presentation 8%
-
Final report 8%
|
|
Assignment 1:
Definitions of basic concepts |
Assess the student’s understanding of the basic
software engineering concepts and your perception of several enterprise
architecture terms and concepts. |
|
Assignment 2:
Case study system architecture |
Develop and analyze an architectural breakdown for the
system described in the case study discussed in class. |
|
Assignment 3:
Example system architecture and
implementation |
Development of a partial architectural description of
the software system from Assignment 2. |
|
Assignment 4:
Example system implementation |
Development of a partial implementation of the
architecture from Assignment 3 using the supplied architecture
implementation infrastructure. |
All work must be your
own. Duplicate lab assignments will be given a grade of "zero". Both the
person copying the assignment and the person supplying the copy will be
penalized equally!
CONDUCT OF COURSE:
Lecture/Discussions, Demos, and Labs:
Class sessions will be
divided between: (1) lecture/discussion of certain software concepts and
features, (2) instructor demonstrations of these same software concepts and
features, and (3) student laboratory sessions working with these same software
concepts and features.
The purpose of this
pedagogical approach is to introduce and reinforce ideas and skill sets so that
students can master these on their own after class hours. To bring this
knowledge to a highly proficient, professional level, students will have to
spend time and effort outside of class working in the GSU computer labs or on
their own micros.
To ensure that you have the
basic knowledge that will allow you to function on your own after class, be sure
to ask the instructor questions during class, either during the
lecture/discussion, demo, or lab.
POLICIES:
Grading Policy
|
Mid Term |
20% |
|
Class project |
25% |
|
Assignment 1 |
5% |
|
Assignment 2 |
5% |
|
Assignment 3: |
5% |
|
Assignment 4: |
10% |
|
Class Participation |
30% |
|
Total |
100% |
Withdrawing
A 'W' grade will be
assigned if a student withdraws before the middle of the semester while
maintaining a passing grade. A 'WF' will be assigned if a student withdraws
before the middle of the semester while doing failing work OR after the middle
of the semester. Missing more than two consecutive classes without the
instructor's permission will be considered a voluntary withdrawal. The grade of
'W' or 'WF' will depend upon whether the student stopped actively attending
prior to the mid-point of the semester.
Class
participation
Expectations regarding attendance and class participation:
Since this is a case-based and discussion-oriented course, regular attendance and participation is required. In evaluating your class participation in discussions of cases and articles, both the quantity and quality of participation is taken into account. As a wise professor once said: "You can't have any quality if you don't have any quantity and you can't have any quantity if you aren't in class."
Absences will have an adverse effect on your participation score for the course. Students are therefore expected to attend all classes, except when precluded by emergencies, religious holidays, or other extenuating circumstances. If you will be absent from class for any reason, please notify me in advance if possible.
It is reasonable to expect on time start for each course session. This is true in our work lives so it is true in the conduct of this class. Classes will begin on time. Material missed due to late arrival should be acquired from classmates or project team members. Quizzes or presentations missed due to late arrival will be graded at a zero.
Simply showing up for class, important as it may be, is not to be equated with participation. Students should make an effort to contribute to each and every class discussion. Before coming to class, thorough preparation of each case (and associated articles) is essential. The case method of teaching is only effective when participants have extensively analyzed each case and are prepared to contribute to the case discussion. Students should expect to be "cold called" throughout the course and should be prepared accordingly. This is a normal part of case method teaching. The quality of your contributions to case discussions will be evaluated using the following criteria:
Things I view positively in marking discussion participation include:
·
Does the contribution represent a solid analysis and some insight into the case or is it just a reiteration of case facts?
·
Does the contribution demonstrate an ability to listen to and build from what others have said?
·
Does the contribution demonstrate useful ideas, coherently and succinctly expressed
·
Does the contributor regard, respect and acknowledge other's contributions If the contributor disagrees with other's positions or analysis does s/he offer constructive disagreement
·
Does the contributor demonstrate a good sense of humor'
·
Does the contribution move the discussion to an important area or does it just rephrase what has already been said?
·
If "cold called," was the student prepared?
Things I view negatively in marking discussion participation include:
·
∑lack of involvement - silence, detachment or disinterest
·
∑leading our discussion into unrelated topics
·
∑spending undue amount of time on minor points
·
∑long, rambling comments.
·
∑being absent or unprepared, or passing on a cold call
Expectations for Written assignments and presentations
I expect professional looking documents which give proper credit to all sources of intellectual material. Deliverable documents must be:
·
Typed, (word processed) spell checked and paginated, with suitable.
·
All authors must be identified. Generally a title page is required except on executive memoranda.
·
All citations must be identified in the text (in short form) and in an attached bibliography. Use any standard format as long as it is used consistently.
See the Turabian Manual of Style, Chicago Manual of Style, Harvard Manual or other suitable reference guide to writers if you are not familiar with this requirement. Papers which do not properly cite sources will be returned upgraded. I also recommend that you acquire a copy of the software EndNote to assist in citations and bibliography preparation if you will be doing any academic or professional writing. C.f., www.Endnote.com for more information.
In addition to paper copies of assignments, electronic (and certifiably virus free) copies should be emailed to me on the day they are due.
·
File names should clearly identify you by last name followed by the assignment number. E.g., cis8660 Truex case#1-Amazon
GENERAL CLASS POLICIES:
-
Prerequisites are
strictly enforced. Students failing to complete a prerequisites with a grade
of “C” or higher will be administratively withdrawn from the course in which
they are in violation with a loss of tuition fees. There are no exceptions.
-
Students are expected to attend all classes and group meetings, except when
precluded by emergencies, religious holidays or bona fide extenuating
circumstances.
-
Make-up exams will not
be given. However, if a student has a planned absence, he or she may take the
exam earlier with the permission of the instructor.
-
Students who, for
non-academic reasons beyond their control, are unable to meet the full
requirements of the course should notify the instructor. Incompletes may be
given if a student has ONE AND ONLY ONE outstanding assignment.
-
A “W” grade will be
assigned if a student withdraws before mid-semester while maintaining a
passing grade. Withdrawals after the mid-semester date will result in a grade
of “WF”. Refer to GSU catalog or Registrar’s office for details.
-
Spirited class
participation is encouraged and informed discussion in class is expected. This
requires completing readings and assignments before class.
-
Unless specifically
stated by the instructor, all exams and lab assignments are to be completed by
the student alone.
-
Within group
collaboration is allowed on project work. Collaboration between project groups
will be considered cheating unless specifically allowed by an instructor.
-
Copy work from the
Internet without a proper reference will be considered plagiarism and subject
to disciplinary action as delineated in the Student Handbook.
-
Any non-authorized collaboration will be considered cheating and the student(s)
involved will have an Academic Dishonesty charge completed by the instructor
and placed on file in the Dean’s office and the CIS Department. All
instructors regardless of the type of assignment will apply this Academic
Dishonesty policy equally to all students. See excerpt from the Student
Handbook below:
ACADEMIC HONESTY:
(Abstracted from GSU’s
Student Handbook Student Code of Conduct “Policy on Academic Honesty and
Procedures for Resolving Matters of Academic Honesty” -
http://www.gsu.edu/~wwwcam/academichonesty.html)
Students are responsible for the information contained in this website.
As members of the
academic community, students are expected to recognize and uphold
standards of intellectual and academic integrity. The
University assumes as a basic and minimum standard of conduct in academic
matters that students be honest and that they submit for credit only the
products of their own efforts. Both the ideals of scholarship and the need for
fairness require that all dishonest work be rejected as a basis for academic
credit. They also require that students refrain from any and all forms of
dishonorable or unethical conduct related to their academic work.
Students are expected to
discuss with faculty the expectations regarding course assignments and standards
of conduct. Here are some examples and definitions that clarify the standards by
which academic honesty and academically honorable conduct are judged at GSU.
Plagiarism.
Plagiarism is presenting another person’s work as one’s own. Plagiarism includes
any paraphrasing or summarizing of the works of another person without
acknowledgment, including the submitting of another student’s work as one’s own.
Plagiarism frequently involves a failure to acknowledge in the text, notes, or
footnotes the quotation of the paragraphs, sentences, or even a few phrases
written or spoken by someone else. The submission of research or completed
papers or projects by someone else is plagiarism, as is the unacknowledged use
of research sources gathered by someone else when that use is specifically
forbidden by the faculty member. Failure to indicate the extent and nature of
one’s reliance on other sources is also a form of plagiarism. Failure to
indicate the extent and nature of one’s reliance on other sources is also a form
of plagiarism. Any work, in whole or part, taken from the internet or other
computer based resource without properly referencing the source (for example,
the URL) is considered plagiarism. A complete reference is required in order
that all parties may locate and view the original source. Finally, there may be
forms of plagiarism that are unique to an individual discipline or course,
examples of which should be provided in advance by the
faculty member. The student is responsible for understanding the legitimate use
of sources, the appropriate ways of acknowledging academic, scholarly or
creative indebtedness, and the consequences of violating this responsibility.
Cheating on Examinations.
Cheating on examinations involves giving or receiving unauthorized help before,
during, or after an examination. Examples of unauthorized help include the use
of notes, texts, or “crib sheets” during an examination (unless specifically
approved by the faculty member), or sharing information with another student
during an examination (unless specifically approved by the faculty member).
Other examples include intentionally allowing another student to view one’s own
examination and collaboration before or after an examination if such
collaboration is specifically
forbidden by the faculty member.
Unauthorized
Collaboration. Submission for
academic credit of a work product, or a part thereof, represented as its being
one’s own effort, which has been developed in substantial collaboration with
assistance from another person or source, or computer honesty. It is also a
violation of academic honesty knowingly to provide such assistance.
Collaborative work specifically authorized by a faculty member is allowed. \
Tentative Schedule
The course syllabus provides a general plan for the course;
deviations may be necessary.
|
Week |
Topic |
Readings |
Assignments and Exams |
|
1 |
Course introduction
|
|
|
|
Origins of enterprise
architectures |
-
F. P. Brooks, Jr. No Silver Bullet: Essence and
Accidents of Software Engineering. IEEE Computer, April 1987.
-
B. W. Boehm and W. L. Scherlis. Megaprogramming.
Software Technology Conference 1992, Los Angeles, April 1992.
|
|
|
2 |
Introduction to enterprise
architectures |
|
|
|
Scope of enterprise
architectures:
Canonical case studies |
|
|
|
3 |
Scope of enterprise
architectures:
C4 case study analysis |
|
|
|
Scope of enterprise
architectures:
Distributed flight simulation case study analysis |
|
|
|
4 |
Software architects: People
and teams |
-
P. Kruchten. The Software Architect and the Software
architecture Team. 1st Working IFIP Conference on Software
architectures, San Antonio, TX, February 1999.
|
|
|
Project suggestions
|
|
|
|
5 |
Arriving at an architecture
|
-
Chapter 4-5
-
D. L. Parnas. On the Criteria To Be Used in
Decomposing Systems into Modules. Communications of the ACM,
December 1972.
-
P. Kruchten. Mommy, Where Do Software architectures
Come from? 1st International Workshop on Architectures for
Software Systems, Seattle, WA, April 1995.
-
P. Gruenbacher et al. Reconciling Software
Requirements and Architectures with Intermediate Models. Journal on
Software and System Modeling, December 2003.
|
|
|
Project discussion
|
|
|
|
6 |
Architecture description
languages (ADLs) |
|
|
|
ADL Examples
|
|
|
|
7 |
Domain-specific software
architectures (DSSA) |
-
Chapter 14
-
W. Tracz. DSSA (Domain-Specific Software
architecture) Pedagogical Example. ACM SIGSOFT Software Engineering
Notes, July 1995.
-
D. E. Perry. Generic Descriptions for Product Line
Architectures. 2nd International Workshop on Development and
Evolution of Software architectures for Product Families (ARES II),
Las Palmas de Gran Canaria, Spain, February 1998.
|
|
|
Architectural styles
|
|
|
|
8 |
Mid term exam review
|
|
Mid Term Exam |
|
9 |
Service Oriented
Architecture |
Channabasavaiah,
Holley,
and Tuggle, Migrating to Service Oriented Architecture,
http://www-106.ibm.com/developerworks/webservices/library/ws-migratesoa/
|
Assignment 3 due |
|
10 |
Software connectors
|
-
Chapter 9.
-
N. R. Mehta et al.
Towards a
Taxonomy of Software Connectors. 22nd International
Conference on Software Engineering, Limerick, Ireland, June 2000.
|
|
|
Dynamism in enterprise
architectures |
-
J. Magee and J. Kramer. Dynamic Structure in Software architectures.
4th ACM SIGSOFT Symposium on the Foundations of Software Engineering,
San Francisco, CA, October 1996.
|
|
|
11 |
Architecture-based testing
and analysis |
|
|
|
12 |
Agile systems
development |
·
Service-Oriented Architecture:
Considerations for Agile Systems,
http://msdn.microsoft.com/architecture/
soa/default.aspx?pull=/library/en-us/dnmaj/html/aj2service.asp |
|
|
13 |
From architecture to
design:
Overview of UML
Role of UML in enterprise
architectures |
|
|
|
From architecture to
implementation |
|
|
|
14 |
Software interconnection
technologies |
-
Chapter 14
-
S. P. Reiss. Connecting Tools Using Message Passing
in the Field Environment. IEEE Software, July 1990.
-
M. J. Maybee et al.
Multilanguage Interoperability in Distributed Systems: Experience Report.
18th International Conference on Software Engineering,
Berlin, Germany, March 1996.
|
|
|
Middleware CORBA
|
|
|
|
15 |
Middleware COM / DCOM /
.NET |
|
|
|
Middleware – JavaBeans and
Enterprise JavaBeans
|
|
|
|
16 |
Final Exam Week
|
|
|