Software architecture has become an important topic in the software engineering community due to development of large-scale complex software systems. At the heart of every well-engineered software system including Web applications is its software architecture. Software architecture deals with the key design decisions underlying a software system, reflected in the system’s high-level building blocks. These building blocks are the components (units of computation in a system), the connectors (models of the interactions between software components), and the configurations (arrangements of software components and connectors, and the rules that guide their composition). Software architectures that are found particularly useful for development of and evolution of families of systems.
In this project, you will need to leverage the architectural techniques learned during the course (e.g., architectural recovery, architectural styles, and domain specific software architectures) and couple with your prior experience with programming/implementation efforts, design and implement a real-world software system, and software engineering tools and techniques.
Project Overview
This case study project will involve architectural recovery of large and complex open source systems and the comparison of their architecture according to important architectural properties (e.g., extensibility, reliability, performance).
In this project, you will perform a case study analysis on the architecture of a set of actual systems related to a Web technologies topic, and report on your findings. Each team member will be expected to write case study report on different systems. Based on the case study report findings, as a team, develop a reference architecture for the selected Web technologies domain. As a team, select a set of large and complex open source systems that address a common set of requirements using different approaches. Each student in the team must work on one system.
This project is worth 60% of the final grade. Although one report per team must be submitted, deliverable points will be divided into individual and team points. Please do include details of who worked on which portions of deliverable in the submission document to aid individual and team grading process.
Goals
The goals of this project are to:
• Provide you with a deep understanding of the practical challenges and benefits of a specific architectural style.
• Allow you to learn about a specific web technology domain.
• Allow you to understand how general tradeoffs in architectural design are managed in practice.
• Learn patterns and solutions developed by other software architects.
• Practice thinking critically about software architecture.
• Develop and apply synthesis skills and judgment in distinguishing between the essential and accidental aspects of a software architecture.
• Acquire experience in documenting a real software architecture.
• Practice technical writing.
Preparation
In the context of this project, a case study is a high-quality, narrative description of a software architecture, with an interpretive perspective on specific set of aspects of the architecture in relevance to Web technologies. The best way to understand what this means is to look at software architecture case study examples.
The second edition of the book Software Architecture in Practice provides 7 case studies for you to examine. Please do note that third (latest) edition of the book does not contain these case studies. You can find PDF file of below listed case study chapters in Blackboard:
• Chapter 3 explores the impact of the modular decomposition of a system on its architectural qualities through an analysis of the A-7E Avionics System.
• Chapter 6 analyzes how systems can be designed for high availability though a study of an air traffic control system.
• Chapter 8 is a case study of the integrability offered by a flight simulation system.
• Chapter 13 is a case study of how interoperability is supported by the World Wide Web.
• Chapter 15 is a case study of the development of a software product line for battleship control systems called CelsiusTech.
• Chapter 16 is a case study of the development of J2EE as an industry-standard computing infrastructure.
• Chapter 17 studies how a mobile application is supported by the J2EE infrastructure.
As you will see, all of the above case studies address a specific aspect (e.g., product line architecture) of a specific system (e.g., CelsiusTech). Your task for this project will be to produce something similar to one of the above. However, our case study will be structured differently and may not contain such an in-depth analysis.
I highly recommend you to read at least one of the above case study chapter comprehensively and have a quick look read of rest of the chapters. Suggest that, within a team, each member read different chapters to maximize team benefit.
Deliverable Submissions
Note that all deliverables for this case study project should be submitted as a team. It is each student’s responsibility to manage your team, divide up work tasks, obtain relevant materials from team members, and put together a team report for submission. All deliverable submissions must be made through Blackboard.
Deliverable 0 – Systems Selection
Due: January 21>>>> (I did that already)
Select one system per team member that meets following criteria:
• Selected systems must be open source.
• Systems must have more than 50,000 lines of code. You can use OpenHub (https://www.openhub.net) for finding appropriate open source software system. OpenHub provides details on the number of lines of code of a system.
• Systems must have a non-trivial feature set, i.e., system must offer multiple functionalities and must be built using more than one common library.
• Systems must be relevant to Web technologies, i.e., either providing a Web-based solution or aiding development of Web applications.
Each team member should select a system that is similar to each other. Select systems that are similar to each other based on feature sets or product domain categories. OpenHub will indicate which other projects are similar. It is important to note that the purpose of this project is not simply to reverse-engineer a system, but to analyze and discuss specific aspects of the system. As a team, each team member will be analyzing a selected system using same set of aspects decided by the team. Thus, selecting a set of systems that have similar requirements and/or functionalities is highly recommended.
The selected system should be large and architecturally interesting. Note that larger does not necessarily mean more work as you only need to focus on few aspects of the system. The system does not need to be open source but you must have access to its source code and be able to report on it freely. You can choose a system that you have contributed to if you did not design its architecture, and if the system is big enough. You are strongly encouraged to discuss your choice of system as a team with the instructor before you submit Deliverable 0.
Submission requirements:
Submit a document containing team name, listing of selected systems, and which team member will assess which system. Remember one system per student. Each student in the class must assess different system.
Deliverable 1 – System Tutorial
Due: February 11>>>> (I did that already)
For each system, describe the system in regards to what it does, the main features, the number of lines of code, the number of contributors, number of commits, number of downloads, the main programming languages used in the system, and estimated cost.
Then, write a step-by-step tutorial on (1) where and how to download the source code, (2) how to compile and install the systemincluding dependencies of the system, (3) how to run system, (4) how to use the system, and (5) demonstrate the system features using a case study example.
The tutorial should contain the following subsections:
Prerequisites:Mandated software requirements to run the system (operating system minimal version, JDK, compiler, system libraries, etc.). It is a good idea to include a link for less-known prerequisites.
Source Code and Dependencies:Steps required to download the source code and the dependencies. This could be a cvs or git command to download the latest source code, a series of step to download a zip file and unzip it, etc. If there are many dependencies that must be individually downloaded, a link to an online list is enough (as long as the process to install these dependencies is explained in the tutorial). Otherwise, you can include an annex containing the links of the dependencies.
Compilation: Steps required to compile the system.
Run:Steps required to run the system.
Sample usage of the system:Provide details of how to use the system. Use a case study example to demonstrate system features and how to use them.
The goal of this deliverable is to ensure that you can download and execute the source code of the systems you will be analyzing. You will probably need to debug your system to understand how the various parts interact together so we want to ensure that all students can “play” with their systems.
Evaluation: 5%
The following criteria will be used to evaluate the report:
Completeness (Individual, 2 pts) Are the instructions complete or are there steps missing?
Quality (Individual, 2 pts) Are the instructions easy to follow, clear, and without typos?
Cohesion (Team, 1 pt) Is the report cohesive: is the same font/spacing used, are the writing styles similar?
Advice:
Sometimes it takes many attempts and many hours to successfully install and run a complex open source systems due to undocumented dependencies or compatibility issues. You may even have to post on the system’s mailing list to get answers to your installation and run issues. The bottom line is: plan ahead and attempt to install the system days before the deliverable due date.
Deliverable 2 – System Architecture>> (this part what I need you to do)
Due: March
Software architecture practice utilizes the concept of architectural views which are representation of a set of system elements and the relations associated with them. There are three architectural view types: module, component-and-connector (C&C), and allocation. Module views displays static structure of the system as a set of implementation units, C&C views displays system runtime behavior characteristics as a set of cooperating units, and allocation views displays how the system is allocated to structures in the system’s environment. In this deliverable, each team member should describe module views, C&C views, and allocation views for the selected system.
The report should contain the following common sections:
Introduction: Present the family of systems you are analyzing, their domain, what features they have in common, how they differ on the surface (e.g., programming language, audience, age, size).
Each system will be presented using these sections:
Overview:Provide an overview of the system in laymen’s terms. Present the main features of the system (especially if they differ from the other system), how the code is organized (e.g., the main folders in the repository, the main packages, naming convention, folder patterns) and how it relates to the features. You can draw a diagram if it helps.
Module View:Provide at least one significant module view of the system using a diagram. Describe the role of each module, how it is represented in the code (e.g., by a package), how it relates to the other modules. If it is only a partial view of the system, mention what is not displayed. You can display a second view if you have the space, but make sure that your first view is well documented and explained. You can use lists or tables to complement your diagram. The view should contain at least five modules.
C&C View:Provide one significant C&C view of the system using a diagram. Describe the relationship between this view and the module view, clearly indicate the type of each connector (e.g., using a legend, in the text, etc.). Explain at least the control flow or the dataflow of a common scenario (e.g., with a sequence diagram, with a list of steps, etc.). If your C&C view does not represent the whole system, mention what is not displayed. Mention any architectural styles that you encountered while recovering the system’s architecture. Describe how your C&C view relates to your module view: the two views do not need to be closely related and they can be about different parts of the systems. The view should contain at least five components.
Connectors: For each connector in the previous C&C view, indicate how they are implemented in the code. For example, name the classes or the methods that are called and which classes or methods are making these calls. Some connectors will be easy to describe because they are implemented in a clean interface (e.g., a Facade), while some connectors are abstracting a set of scattered method calls. In the latter case, you do not need to name each method call, but you need to indicate the main methods. If there are more than 10 connectors, document only the 10 most important ones.
Hint: Numbering the connectors in the C&C view will help tremendously!
Allocation View:Provide one allocation view of the system using a diagram. If the system’s allocation is simple (e.g., it can be represented as one program running on a machine), present a scenario where the system interacts with its environment (e.g., auto-update, accessing a server or being accessed by a client, etc.). Clearly indicate the type of relationships in the diagram, the role of each components, and why you selected this particular view. Describe how your allocation view relates to your two other views.
Conclusion:Informally evaluate the quality of the system’s architecture and implementation. Discuss strengths and relevant weaknesses of the architecture (e.g., it’s easy to add a new operation, but adding a new view is not supported and requires extreme hacking skills.). Briefly discuss evolution (e.g., Did the architecture pass the test of time?; How did the architecture evolve?; What were the motivations?; Does the architecture support backward compatibility?; What was the impact on the components (and potentially client programs)?; Was there any architectural drift?) of the architecture.
Evaluation:15%
Each section will be evaluated according to the following criteria:
Completeness: Are the main artifacts and relationships presented in each section? Is the level of granularity right?
Correctness: Are the diagrams and the text precise? Are the architectural terms used appropriately? Are the artifacts and relationships represented accurately?
Quality: Are the diagrams and the text easy to follow, clear, and logically structured?
Deliverable sections will be graded following below given distribution:
Intro: 1 pt
Overview: 1 pt
Module View: 2 pts
C&C View: 2 pts
Connectors: 2 pts
Allocation View: 2 pts
Conclusion: 1 pt
Report quality: 4 pts
Deliverable 3 – Architecture Comparison (not now)
Due: April 7
In this deliverable, you will compare three aspects of your systems’ architecture. By aspect, we mean feature implementation or non-functional requirements (e.g., extensibility, maintainability, security). The three aspects do not need to be of the same granularity or of the same nature, but we require that one aspect be fine-grained (e.g., a low-level feature).
The report will contain the following sections:
Introduction: present the systems briefly and mention the three aspects of their architecture that will be compared.
Each aspect will then be presented using these subsections.
Aspect Overview: describe the aspect being studied, why it was selected, and how it differs across the systems.
Diagram and Description: draw one diagram of the aspect for each system. Make sure to show not just how the aspect is implemented, but also how it integrates with the architecture. Use the same viewtype for all diagrams in this subsection. Describe each diagram separately. You can draw more than one diagram per system if necessary.
Comparison: compare the systems from the point of view of this aspect. For example, you can describe the different trade-offs each system is making, you can compare the connector types and the architectural styles, you can compare how the general architecture made this aspect easy (or difficult) to implement, etc. Indicate which system has a better architecture from the perspective of this aspect and justify your choice. Make sure that this subsection refers to material seen in class. This is the most important subsection.
At the end of the entire report:
Conclusion: Write a conclusion. Summarize the differences between the systems (from the perspective of your three aspects). Indicate which system has the best architecture according to these three aspects and justify your decision.
Evaluation:20%
Each section will be evaluated according to the following criteria:
Completeness: Are the main artifacts and relationships presented in each section?
Correctness: Are the diagrams and the text precise? Are the architectural terms used appropriately? Are the artifacts and relationships represented accurately?
Quality: Are the diagrams and the text easy to follow, clear, and logically structured?
Deliverable sections will be graded following below given distribution:
Intro: 2 pts (team)
Aspects: 10 pts (3 pts per aspect, 1pt for overall quality)
Conclusion: 2 pts (team)
Report quality: 1 pt (team)
Deliverable 4 – Reference Architecture
Due: April 26
In this deliverable, you will describe a reference architecture of the form invariants plus variation points for the family of systems you studied. During generational evolution of the system, changes in the architecture are very likely to occur. System architectures should encompass these variations into their design. First, find at least five invariants and three variation points in your systems. Then, describe the invariants and the variation points using three viewtypes (module, component and connector, allocation). For each viewtype, identify the invariants and variation points, and indicate how each system fulfill (or not) these invariants and variation points. It is perfectly fine to start from your deliverable 2 report and make it more general.
The report will contain the following common sections:
Introduction: present the family of systems you are analyzing, their domain, what features they have in common, how they differ on the surface (e.g., programming language, audience, age, size).
Domain Model Overview: Present an overview of the reference architecture’s domain model including glossary of most important terms, main objects, main features, and main interactions. You do not need to draw any diagram in this section (but you can if it helps). Make sure to indicate the scope of your reference architecture and the level of granularity. For example, do you assume that all the systems built using that reference architecture will use the same programming language, is there a particular feature not covered at all by your reference architecture.
Module View: provide at least one significant module view of the reference architecture using a diagram. Describe the role of each module, how it relates to the other modules. If it is only a partial view of the reference architecture, mention what is not displayed. You can display a second view if you have the space, but make sure that your first view is well documented and explained. You can use lists or tables to complement your diagram. All the invariants and the variation points of your reference architecture should be presented in this section, even if they do not appear in the view (but really, they should!).
C&C View: provide at least one significant C&C view of the reference architecture using a diagram. Describe the relationship between this view and the module view, clearly indicate the type of each connector (e.g., using a legend, in the text, etc.). If the type of the connectors can vary, mention what types can be used. Explain at least the control flow or the dataflow of a common scenario (e.g., with a sequence diagram, with a list of steps, etc.). If your C&C view does not represent the whole reference architecture, mention what is not displayed. Mention any architectural styles in your reference architecture. The C&C view does not need to be closely related to the module view and they can be about different parts of the reference architecture. The view should contain at least five components.
Hint: Numbering the connectors in the C&C view will help tremendously!
Allocation View: provide one allocation view of the reference architecture using a deployment diagram. If the reference architecture’s allocation is simple (e.g., it can be represented as one program running on a machine), present a scenario where the system interacts with its environment (e.g., auto-update, accessing a server or being accessed by a client, etc.). Clearly indicate the type of relationships in the diagram, the role of each components, and why you selected this particular view. Describe how your allocation view relates to your two other views.
Conclusion:provide brief summary information of your reference architecture. Discuss strengths and relevant weaknesses of the architecture in terms of quality (testability, performance, extensibility) and easiness of implementing it.
Evaluation: 10% (one grade per team)
Each section will be evaluated according to the following criteria:
Completeness: Are the main artifacts and relationships presented in each section? Is the level of granularity right?
Correctness: Are the diagrams and the text precise? Are the architectural terms used appropriately? Are the artifacts and relationships represented accurately?
Quality: Are the diagrams and the text easy to follow, clear, and logically structured?
Deliverable sections will be graded following below given distribution:
Intro: 1 pt
Domain Model: 2 pts
Module View: 2 pts
C&C View: 2 pts
Allocation View: 2 pts
Conclusion: 1 pt
Remember to include details of who worked on which portions of deliverable in the submission document.
Final Report Presentation at the School of Computing Symposium
Due: April 22
CEN 6036 students have option of presenting their case study analysis project work as a poster at the School of Computing Symposium this spring to be held on Friday, April 22, 2016 from 3 PM to 6 PM. Note that you should plan to arrive at the University Center around 2 PM to have sufficient time to check-in and set up your poster.
April 22nd is one of the spring 2016 study break days. If you are not able to present at the symposium due to study break, please contact the instructor during the first week of the course, i.e., on or before January 14, 2016. Instructor will identify alternative public speaking presentation opportunity for those who are not willing to present at the symposium.
TAKE ADVANTAGE OF OUR PROMOTIONAL DISCOUNT DISPLAYED ON THE WEBSITE AND GET A DISCOUNT FOR YOUR PAPER NOW!