Software Design Architecture Comparison

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
m (removed background readings)
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
−
{| border="1"
+
 
−
|-
+
{{Learning Activity Overview
−
|'''Title''' || Software Design and Architecture Comparison (Eclipse vs Openstack)
+
|title=
−
|-
+
Software Design and Architecture Comparison (Eclipse vs OpenStack)
−
|'''Overview''' || Students will research existing software design documents and resources for both projects and then write a report detailing their differences and helpfulness to various levels of developers.
+
|overview=
−
|-
+
Students will learn how to introduce themselves to new and foreign open source communities by researching existing software design documents and resources in two large and popular open source projects. Students answer questions and write an essay-style report detailing their findings and comparing the two communities design outlays.
−
|'''Prerequisite Knowledge''' || Students should have:
+
|prerequisites=
 +
Students should have:
 
* Taken a CS1 course (Introduction to Programming).  
 
* Taken a CS1 course (Introduction to Programming).  
 
** Already learned syntax and the basics of a programming language.
 
** Already learned syntax and the basics of a programming language.
Line 13: Line 14:
 
** Could be delivered along-with this activity
 
** Could be delivered along-with this activity
 
** Ex: [https://en.wikipedia.org/wiki/Software_design_pattern Design Patterns] knowledge
 
** Ex: [https://en.wikipedia.org/wiki/Software_design_pattern Design Patterns] knowledge
−
|-
+
|objectives=
−
|'''Learning Objectives''' || Upon completion, students should:
+
 
* Understand how thoughtful software design is encouraged, or not, in open source communities.
 
* Understand how thoughtful software design is encouraged, or not, in open source communities.
 
* Be able to give examples of software design artifacts, and how to go about finding them.
 
* Be able to give examples of software design artifacts, and how to go about finding them.
 
* Realize what they consider good software design, and be able to back it up with reason.
 
* Realize what they consider good software design, and be able to back it up with reason.
−
* Realize why software design is important, and how it will effect them in their future careers.
+
* Be able to approach a new project and code base with a pattern that they can repeat elsewhere.
−
* Be able to approach a new project and codebase with a pattern that they can repeat elsewhere.
+
|process skills=
−
|}
+
}}
  
−
=== Background: ===
+
=== Background ===
−
What is the rational for this activity?
+
* ''What is the rationale for this activity?''
  
 
For students, who are often novice and beginner developers, it is critical to understand the big-picture when jumping into a new software project. A proper view of the system-wide architecture can bring context on how the entire system works, instead of focus on a particular component. When you can have knowledge of other pieces of the puzzle, you tend to implement better code because it is thoughtful of how your current focus interacts with functionality around it and even to functionality seemingly far-removed. Students need to be aware of why this helps them and their career, how to find this kind of documentation, and that it might shape their opinions and focus when choosing projects to interact with.
 
For students, who are often novice and beginner developers, it is critical to understand the big-picture when jumping into a new software project. A proper view of the system-wide architecture can bring context on how the entire system works, instead of focus on a particular component. When you can have knowledge of other pieces of the puzzle, you tend to implement better code because it is thoughtful of how your current focus interacts with functionality around it and even to functionality seemingly far-removed. Students need to be aware of why this helps them and their career, how to find this kind of documentation, and that it might shape their opinions and focus when choosing projects to interact with.
  
−
Are there any similar activities?
+
* ''Are there any similar activities?''
  
 
See [[OpenMRS_Design_Reverse_Engineering_Activity_(Android_App)]] for an activity that has students reverse engineer a design / architecture from an existing open source Android applications codebase.
 
See [[OpenMRS_Design_Reverse_Engineering_Activity_(Android_App)]] for an activity that has students reverse engineer a design / architecture from an existing open source Android applications codebase.
Line 33: Line 33:
  
  
−
=== Directions: ===
+
=== Directions ===
  
−
==== Part 1: Exploring Eclipse and OpenStack ====
+
In this activity, we will focus on the Eclipse IDE (Platform) project and the OpenStack cloud project. Below, you will learn about these projects and their open communities. After this, you will compare and contrast the design and architecture artifacts available in these communities. Both projects are open source and very large, with many hundreds of participants. Be aware that you will not be able to immediately jump into the code of these type projects. We will take a process below where we progress our knowledge bit by bit. You can easily use this process again for future projects.
−
In this activity, we will focus on the Eclipse IDE (Platform) project and the OpenStack cloud project. Below, you will learn about these projects and their open communities. After this, you will compare and contrast the design and architecture artifacts available in these communities. Both projects are open source and very large, with many hundreds of participants. Be aware that you will not be able to immediately jump into the code of these projects. We will take a process below where we progress our knowledge bit by bit. You can easily use this process again for future projects.
+
  
 +
==== Part 1: Discover Eclipse and OpenStack ====
 +
[https://eclipse.org/ide/ Eclipse] is an Integrated Development Environment (IDE) that runs on desktop computers. An IDE is basically a fancy code-editor for developers who are creating software. A developer needs to not only edit code in text files, but also to run the code, debug the code, and step through the code one-line at a time looking for bugs. Note: Do not confuse the 'Eclipse IDE' with the 'Eclipse Foundation', which was created after the successful IDE and now encompasses hundreds of open source projects.
  
−
Because these are projects that you may know little or nothing about, first delve into the basics:
+
[https://www.openstack.org/ OpenStack] is a cloud infrastructure platform. This means, that it can provide businesses a platform to setup their own self-service infrastructure cloud system. For example, a large bank wants their technical sales people as well as developers to be able to spin up virtual machines for work purposes with ease - no more making a request to IT, or waiting for a physical server. OpenStack allows this scenario to play out, as well many others. It has been compared to the next Linux - an uber-successful open source ecosystem that shifts the industry.
−
* Gather a quick understanding of each project from a user's point of view.  
+
 
 +
Because these are projects that you may know little or nothing about, you first need to do some research into the basics:
 +
* Gather a quick understanding of each project from a user's point of view. Google them, wikipedia them, and look all over their websites.
 
* What functionality does each project provide its users? It may be helpful to read third party reviews or descriptions, as wikipedia and project websites often do not have beginner descriptions that give you enough context.  
 
* What functionality does each project provide its users? It may be helpful to read third party reviews or descriptions, as wikipedia and project websites often do not have beginner descriptions that give you enough context.  
 
* Next, gather some technical statistics. Use tools such as Ohloh (now [https://www.openhub.net OpenHub]) to get general technical stats and background.  
 
* Next, gather some technical statistics. Use tools such as Ohloh (now [https://www.openhub.net OpenHub]) to get general technical stats and background.  
Line 48: Line 51:
  
  
−
The next step is delving into the high-level design or architecture of each project. Below are a list of required reading resources. In addition to these, you should do your own research to find the most up-to-date resources pertaining to the projects software design and architecture. Software and documentation change drastically over time, so do your own search.
 
  
−
Think about the following questions when reading below:
+
==== Part 2: Find Design and Architecture Artifacts ====
 +
The next step is delving into the high-level design or architecture of each project. Below are a list of required reading resources. In addition to these, you should do your own research to find the most up-to-date resources pertaining to the projects software design and architecture. Software and documentation change drastically over time, so do your own additional research.
 +
 
 +
Think about and answer the following questions when reading below:
 
* How do high-level modules and packages work together?  
 
* How do high-level modules and packages work together?  
 
* Does the project have a data layer or store?  
 
* Does the project have a data layer or store?  
Line 61: Line 66:
 
** By Amy Brown and Greg Wilson; Licensed under [http://creativecommons.org/licenses/by/3.0/legalcode CC BY 3.0]
 
** By Amy Brown and Greg Wilson; Licensed under [http://creativecommons.org/licenses/by/3.0/legalcode CC BY 3.0]
 
* Read the following discussion on OpenStacks developer maillist: [http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#85707 Email list discussion on design and architecture]
 
* Read the following discussion on OpenStacks developer maillist: [http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#85707 Email list discussion on design and architecture]
−
** Additionally, skim through the following [http://docs.openstack.org/infra/manual/developers.html Developers Guide] - Does this describe OpenStacks design from a software standpoint?
+
** Additionally, skim through the following [http://docs.openstack.org/infra/manual/developers.html Developers Guide] - think to yourself, Does this describe OpenStacks design from a software standpoint?
  
 
Look for additional information:
 
Look for additional information:
Line 68: Line 73:
 
** https://wiki.eclipse.org/Learn_About_Eclipse
 
** https://wiki.eclipse.org/Learn_About_Eclipse
 
** http://www.eclipse.org/articles/Whitepaper-Platform-3.1/eclipse-platform-whitepaper.pdf
 
** http://www.eclipse.org/articles/Whitepaper-Platform-3.1/eclipse-platform-whitepaper.pdf
−
** htp://www.eclipse.org/eclipse/
+
** http://www.eclipse.org/eclipse/
 
* Find additional readings around design/architecture in OpenStack. Start here:
 
* Find additional readings around design/architecture in OpenStack. Start here:
−
** [http://docs.openstack.org/openstack-ops/content/example_architecture.html Logical Architecture] - A diagram of their architecture from user's pov. Does this document give an explanation of their back-end software design?
+
** [http://docs.openstack.org/openstack-ops/content/example_architecture.html Logical Architecture] - A diagram of their architecture from a user's pov. Think to yourself, does this document give an explanation of their back-end software design?
−
** [http://docs.openstack.org/project-team-guide/open-design.html Open Design explanation] - Note that this is mostly a description of their Design Summits (gatherings twice a year). Does this explain their software design in-depth?
+
** [http://docs.openstack.org/project-team-guide/open-design.html Open Design explanation] - Note that this is mostly a description of their Design Summits (gatherings twice a year). Think to yourself, does this explain their software design in-depth?
  
  
  
−
==== Part 2: Comparing Designs and Architectures ====
+
==== Part 3: Compare Designs and Architectures ====
−
FIXME SECTION NOT IMPLEMENTED - The idea in this section will be to compare and contrast the documentation and artifacts of software design and architecture between Eclipse and OpenStack. Generally, OpenStack is a younger faster moving project, so they self-admittedly do not have good documents, process or artifacts to encourage healthy software design. Students will be pushed down this road, via a discussion that was had on OpenStacks maillist. Questions and a writeup around these differences will be covered by the students.
+
Now that you have scoured the above communities and learned about them at a working-level, we will compare and contrast the documentation, artifacts, and processes found between Eclipse and OpenStack. Questions and a comparative write-up around these differences will be covered.
 +
 
 +
You will need to write a two-section essay-style paper, one section that answers some specific questions, and another that compares your observations of both communities.
 +
 
 +
===== Specific Questions =====
 +
Write in essay/paragraph style and keep these answers short. 1-3 sentences each. Provide URL links when useful.
  
 
Eclipse-specific questions:
 
Eclipse-specific questions:
Line 83: Line 93:
 
* Explain Eclipse's decision to refactor and generalize their bundles for RCP applications.
 
* Explain Eclipse's decision to refactor and generalize their bundles for RCP applications.
 
* These design decisions opened their software up to uses they had not dreamt of, such as monitoring the Mars rover. How is this a perfect example of software reuse and modularization?
 
* These design decisions opened their software up to uses they had not dreamt of, such as monitoring the Mars rover. How is this a perfect example of software reuse and modularization?
 +
 +
OpenStack-specific questions:
 +
* How does OpenStack engrain successful design into its code? Recall the discussion at http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#85707
 +
* What are OpenStacks Design summits? How often are they, and what purposes do they serve?
 +
* What are OpenStacks "specs", "blueprints", and "review" processes / tools? How might they effect a developers decisions around design and architecture?
 +
* What is OpenStack Oslo? It has not existed since the start of the project - how did it come about?
 +
 +
===== Community Comparison =====
 +
 +
Write a 5 to 10 paragraph (1-3 page) essay that describes:
 +
# What you found in each community - particularly artifacts not listed above.
 +
# Which community had more or less of which types of artifacts (architecture diagrams, software design patterns, review processes, etc).
 +
# What you believe to be the pro's and the con's of each community in respect to software design and architecture. We are looking for your educated opinion here.
 +
# What could each community learn from each other?
 +
# What did you learn from this activity? How could you see yourself taking the process used here on other future tasks?
 +
 +
If you get stuck on this, try listing out as many web resources as you can from when you researched each of the communities. Once you list each of them out, side by side, you can draw lines from each side when you see an equivalent resource in the other community. You will be left with matching resources across both communities, and unmatched resources. Now, talk about these similarities and differences in paragraph form.
 +
 +
It is important for you to make an opinion on which community you think is doing what better. There will not be correct or incorrect answers here, but instead the process of how you came to that conclusion and how you defend it, are what will be graded. The act of coming to and defending a position around software design and process can be just as important as implementation details - especially in communities of hundreds of developers, where you will need to understand and convince people of just these things in order to get your ideas included.
  
  
  
 +
=== Deliverables ===
  
−
=== Deliverables: ===
 
 
Students will deliver:
 
Students will deliver:
−
# For Part 1, their answers to the following questions:
+
# For Part 1, answers to 4 questions.
−
#* What functionality does each project provide its users? (1-2 paragraphs)
+
# For Part 2, answers to 3 questions, and 1 bonus question.
−
#* What programming languages are used? Which one(s) is major, which ones are minor?
+
# For Part 3, write an essay-style paper that answers:
−
#* What percentage of the code are comments?
+
#* All Eclipse-specific questions (1-3 sentences each)
−
#* Mention other general statistics or information that might be helpful when reading into a projects design and architecture.
+
#* All OpenStack-specific questions (1-3 sentences each)
−
#* How do high-level modules and packages work together?
+
#* A 5 to 10 paragraph (1-3 page) essay describing:
−
#* Does the project have a data layer or store?
+
#** What you found in each community.
−
#* How does each system weave the user into their architecture?
+
#** Artifact distribution in each community.
−
#* (bonus) Are there any design patterns that you saw mentioned or that you think might be used? Do not focus on being 100% correct - take some guesses and explain why.
+
#** Pro and con opinions of the two communities studied.
−
#* Does OpenStacks "Open Design explanation" explain their software design in depth?
+
#** Possible lessons learned.
−
# For Part 2,
+
−
#*
+
−
#*
+
−
#*
+
  
  
−
=== Assessment: ===
 
−
How will the activity be graded?
 
−
 
−
How will learning will be measured?
 
  
−
Include sample assessment questions/rubrics.
+
=== Assessment ===
  
 
{| border="1" class="wikitable"
 
{| border="1" class="wikitable"
Line 119: Line 140:
 
! Level 4 (exceptional)
 
! Level 4 (exceptional)
 
|-
 
|-
−
| '''The purpose of the project'''
+
| '''Understands how software design is encouraged in open source'''
−
|  
+
| Little to no understanding shown; Answers are made up or unrelated; Didn't read material
−
|  
+
| Limited understanding, showing that they read some, but did not dig very deep
−
|
+
| Showed that they looked into the two communities and synthesized how they each encourage (or didnt) good design
−
|
+
| Synthesized good/bad design outcomes via their own exploration of the topic (beyond links given here in the activity)
  
 
|-
 
|-
−
| '''Why the project is open source'''
+
| '''Finds software design artifacts'''
−
|  
+
| Did not read artifacts linked to here in activity
−
|  
+
| Read artifacts mentioned here, but did not seek out any of their own
−
|  
+
| Read artifacts mentioned here, and found some of their own, but did not utilize them profoundly in their write-up
−
|  
+
| Found their own new artifacts, explained how they found them, and wove them into their papers findings
 +
 
 +
|-
 +
| '''Forms their own position on what is good software design'''
 +
| Did not attempt to express their position
 +
| Minimal expression; For example, they say that a lack of artifacts and documentation is bad, but they dont give details; Too generalized
 +
| Well-formed opinion that is backed by details; Being "right" doesn't matter as much as reasoning behind why
 +
| Well-formed opinions that are expertly backed by myriads of URLs to proof as to why they are right
 +
 
 +
|-
 +
| '''Gains a method of approaching new projects'''
 +
| Did not attempt to learn a wider pattern; Failed above other objectives
 +
| Answered the questions matter-of-fact and did not expand on their searches into each community
 +
| Explicitly expressed how they might re-use this lesson to the particular context of software design research
 +
| Expressed in their essay how this method could be used in any open source project exploration, not just software design
  
 
|}
 
|}
  
−
=== Comments: ===
+
=== Comments ===
−
What should the instructor know before using this activity?
+
* ''What should the instructor know before using this activity?''
  
−
Encourage students to find new design and architecture information. They should be scouring the sites wiki's, code, documentation, etc. Because these communities are large, their resources will grow and change over time. What was there one semester, may not be there another semester. Or, they may add design documentation that formerly was not there. The links given to students should be a guide - they are not exhaustive.
+
* Encourage students to find new design and architecture information. They should be scouring the sites wiki's, code, documentation, etc.  
 +
* The links given to students should be a guide - they are not exhaustive.
 +
* Because these communities are large, their resources will grow and change over time. What was there one semester, may not be there another semester. Or, they may add design documentation that formerly was not there.  
  
−
What are some likely difficulties that an instructor may encounter using this activity?
+
* ''What are some likely difficulties that an instructor may encounter using this activity?''
  
 +
* This activity asks for a lot of reading and writing. Certain students may not excel at this, or will take considerably longer to finish it than with other students.
 +
* Additionally, this activity asks student to form and communicate their own opinion. It may take prodding for certain students to feel comfortable with doing this.
  
−
=== Additional Information: ===
 
−
{| border="1"
 
−
|-
 
−
|'''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]
 
−
|-
 
−
|'''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf
 
−
|-
 
−
|'''Level of Difficulty''' || Is this activity easy, medium or challenging?
 
−
|-
 
−
|'''Estimated Time to Completion''' ||  How long should it take for the student to complete the activity?
 
−
|-
 
−
|'''Materials/Environment''' || What does the student need?  Internet access, IRC client, Git Hub account, LINUX machine, etc.?
 
−
|-
 
−
|'''Author''' || Nick Yeates
 
−
|-
 
−
|'''Source''' || Is there another activity on which this activity is based?  If so, please provide a link to the original resource.
 
−
|-
 
−
|'''License''' || Creative Commons CC-BY
 
−
|}
 
  
−
=== Suggestions for Open Source Community: ===
 
−
Suggestions for an open source community member who is working in conjunction with the instructor.
 
  
 +
=== Additional Information ===
  
−
--------------------
+
{{Learning Activity Info
−
This work is licensed under a
+
|acm unit=
−
[http://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International License]
+
SDF/Algorithms and Design; SE/Software Design
 +
|acm topic=
 +
Fundamental design concepts and principles;
 +
Structural and behavioral models of software designs;
 +
System design principles;
 +
Software architecture concepts and standard architectures;
 +
Measurement and analysis of design quality
 +
|difficulty=
 +
easy to medium
 +
|time=
 +
3-8 hours (different students will vary wildly b/c of their reading/writing/deduction skills)
 +
|environment=
 +
* Internet access
 +
* Word processor - Some way to write their essay and answers
 +
|author=
 +
Nick Yeates
 +
|source=
 +
|license=
 +
{{License CC BY}}
 +
}}
 +
 
 +
=== Suggestions for Open Source Community: ===
 +
* ''Suggestions for an open source community member who is working in conjunction with the instructor.''
  
−
[[Category: Learning_Activity]]
+
* Review with students what software design artifacts and processes exist in your project. Where does there need improvement? Be honest with them. Many opensource projects don't have the resources for this, or design is handled in other ways.
−
[[Category: Specification_and_Design]]
+
* Brainstorm with students on how they could help to improve your projects software design and architecture documents, diagrams, processes and artifacts. Maybe the students can put together high-level architecture diagrams that are friendly to new community developers.
−
[[Category: Coding_and_Style]]
+
  
  
Line 247: Line 287:
 
** http://www.aosabook.org/en/eclipse.html
 
** http://www.aosabook.org/en/eclipse.html
  
−
 
+
[[Category:Learning Activity]]
−
==== Project Descriptions ====
+
[[Category:Specification and Design]]
−
These are being cut for now, because students should figure this out. FIXME think of bringing up a few key sentences to above.
+
[[Category:Coding and Style]]
−
 
+
[[Category:CS2]]
−
Eclipse is an Integrated Development Environment (IDE) that runs on desktop computers. An IDE is basically a fancy code-editor for developers who are creating software. A developer needs not only edit code in text files, but also to run the code, debug the code (possibly stepping through the code one-line at a time, looking for a bug), they need to see hierarchical views of the classes, and have ease-of-use functions like code completion (you can't remember which function you want to use, and the IDE gives you a list of choices while you are typing). Eclipse centers on Java development, though it is also usable for dozens of other languages. Do not confuse the 'Eclipse IDE' with the 'Eclipse Foundation', which was created after the successful IDE and now encompasses hundreds of open source project.
+
[[Category:Ready to Use]]
−
 
+
−
OpenStack is a cloud infrastructure platform. FIXME Bacon ipsum dolor amet venison short loin porchetta, cow picanha swine corned beef tri-tip fatback pork belly sirloin landjaeger leberkas. Capicola ball tip ham fatback hamburger alcatra short ribs shoulder meatloaf corned beef tri-tip pancetta brisket. Salami biltong kielbasa swine porchetta cupim. Hamburger tongue sirloin drumstick boudin corned beef ham shoulder ground round meatloaf ribeye alcatra tri-tip landjaeger kielbasa. Chicken strip steak kevin turkey drumstick bresaola salami bacon ground round. Kevin picanha sirloin tri-tip jerky.
+

Latest revision as of 12:05, 8 September 2018


Title

Software Design and Architecture Comparison (Eclipse vs OpenStack)

Overview

Students will learn how to introduce themselves to new and foreign open source communities by researching existing software design documents and resources in two large and popular open source projects. Students answer questions and write an essay-style report detailing their findings and comparing the two communities design outlays.

Prerequisites

Students should have:

  • Taken a CS1 course (Introduction to Programming).
    • Already learned syntax and the basics of a programming language.
    • Already learned simple data structures.
  • Rudimentary software design knowledge
    • Could be delivered along-with this activity
    • Ex: Design Patterns knowledge
Learning
Objectives 		After successfully completing this activity, the learner should be able to:
  • Understand how thoughtful software design is encouraged, or not, in open source communities.
  • Be able to give examples of software design artifacts, and how to go about finding them.
  • Realize what they consider good software design, and be able to back it up with reason.
  • Be able to approach a new project and code base with a pattern that they can repeat elsewhere.
Process Skills
Practiced


Background

  • What is the rationale for this activity?

For students, who are often novice and beginner developers, it is critical to understand the big-picture when jumping into a new software project. A proper view of the system-wide architecture can bring context on how the entire system works, instead of focus on a particular component. When you can have knowledge of other pieces of the puzzle, you tend to implement better code because it is thoughtful of how your current focus interacts with functionality around it and even to functionality seemingly far-removed. Students need to be aware of why this helps them and their career, how to find this kind of documentation, and that it might shape their opinions and focus when choosing projects to interact with.

  • Are there any similar activities?

See OpenMRS_Design_Reverse_Engineering_Activity_(Android_App) for an activity that has students reverse engineer a design / architecture from an existing open source Android applications codebase.


Directions

In this activity, we will focus on the Eclipse IDE (Platform) project and the OpenStack cloud project. Below, you will learn about these projects and their open communities. After this, you will compare and contrast the design and architecture artifacts available in these communities. Both projects are open source and very large, with many hundreds of participants. Be aware that you will not be able to immediately jump into the code of these type projects. We will take a process below where we progress our knowledge bit by bit. You can easily use this process again for future projects.

Part 1: Discover Eclipse and OpenStack

Eclipse is an Integrated Development Environment (IDE) that runs on desktop computers. An IDE is basically a fancy code-editor for developers who are creating software. A developer needs to not only edit code in text files, but also to run the code, debug the code, and step through the code one-line at a time looking for bugs. Note: Do not confuse the 'Eclipse IDE' with the 'Eclipse Foundation', which was created after the successful IDE and now encompasses hundreds of open source projects.

OpenStack is a cloud infrastructure platform. This means, that it can provide businesses a platform to setup their own self-service infrastructure cloud system. For example, a large bank wants their technical sales people as well as developers to be able to spin up virtual machines for work purposes with ease - no more making a request to IT, or waiting for a physical server. OpenStack allows this scenario to play out, as well many others. It has been compared to the next Linux - an uber-successful open source ecosystem that shifts the industry.

Because these are projects that you may know little or nothing about, you first need to do some research into the basics:

  • Gather a quick understanding of each project from a user's point of view. Google them, wikipedia them, and look all over their websites.
  • What functionality does each project provide its users? It may be helpful to read third party reviews or descriptions, as wikipedia and project websites often do not have beginner descriptions that give you enough context.
  • Next, gather some technical statistics. Use tools such as Ohloh (now OpenHub) to get general technical stats and background.
  • What programming languages are used? Which one(s) is major, which ones are minor?
  • What percentage of the code are comments?
  • Mention other general statistics or information that might be helpful when reading into a projects design and architecture.


Part 2: Find Design and Architecture Artifacts

The next step is delving into the high-level design or architecture of each project. Below are a list of required reading resources. In addition to these, you should do your own research to find the most up-to-date resources pertaining to the projects software design and architecture. Software and documentation change drastically over time, so do your own additional research.

Think about and answer the following questions when reading below:

  • How do high-level modules and packages work together?
  • Does the project have a data layer or store?
  • How does each system weave the user into their architecture?
  • (bonus) Are there any design patterns that you saw mentioned or that you think might be used? Do not focus on being 100% correct - take some guesses and explain why.


Required Reading:

Look for additional information:


Part 3: Compare Designs and Architectures

Now that you have scoured the above communities and learned about them at a working-level, we will compare and contrast the documentation, artifacts, and processes found between Eclipse and OpenStack. Questions and a comparative write-up around these differences will be covered.

You will need to write a two-section essay-style paper, one section that answers some specific questions, and another that compares your observations of both communities.

Specific Questions

Write in essay/paragraph style and keep these answers short. 1-3 sentences each. Provide URL links when useful.

Eclipse-specific questions:

  • Explain the plugin concept and why it is centrally important to Eclipse.
  • Which component model did Eclipse switch to and why?
  • Explain Eclipse's decision to refactor and generalize their bundles for RCP applications.
  • These design decisions opened their software up to uses they had not dreamt of, such as monitoring the Mars rover. How is this a perfect example of software reuse and modularization?

OpenStack-specific questions:

  • How does OpenStack engrain successful design into its code? Recall the discussion at http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#85707
  • What are OpenStacks Design summits? How often are they, and what purposes do they serve?
  • What are OpenStacks "specs", "blueprints", and "review" processes / tools? How might they effect a developers decisions around design and architecture?
  • What is OpenStack Oslo? It has not existed since the start of the project - how did it come about?
Community Comparison

Write a 5 to 10 paragraph (1-3 page) essay that describes:

  1. What you found in each community - particularly artifacts not listed above.
  2. Which community had more or less of which types of artifacts (architecture diagrams, software design patterns, review processes, etc).
  3. What you believe to be the pro's and the con's of each community in respect to software design and architecture. We are looking for your educated opinion here.
  4. What could each community learn from each other?
  5. What did you learn from this activity? How could you see yourself taking the process used here on other future tasks?

If you get stuck on this, try listing out as many web resources as you can from when you researched each of the communities. Once you list each of them out, side by side, you can draw lines from each side when you see an equivalent resource in the other community. You will be left with matching resources across both communities, and unmatched resources. Now, talk about these similarities and differences in paragraph form.

It is important for you to make an opinion on which community you think is doing what better. There will not be correct or incorrect answers here, but instead the process of how you came to that conclusion and how you defend it, are what will be graded. The act of coming to and defending a position around software design and process can be just as important as implementation details - especially in communities of hundreds of developers, where you will need to understand and convince people of just these things in order to get your ideas included.


Deliverables

Students will deliver:

  1. For Part 1, answers to 4 questions.
  2. For Part 2, answers to 3 questions, and 1 bonus question.
  3. For Part 3, write an essay-style paper that answers:
    • All Eclipse-specific questions (1-3 sentences each)
    • All OpenStack-specific questions (1-3 sentences each)
    • A 5 to 10 paragraph (1-3 page) essay describing:
      • What you found in each community.
      • Artifact distribution in each community.
      • Pro and con opinions of the two communities studied.
      • Possible lessons learned.


Assessment

Criteria Level 1 (fail) Level 2 (pass) Level 3 (good) Level 4 (exceptional)
Understands how software design is encouraged in open source Little to no understanding shown; Answers are made up or unrelated; Didn't read material Limited understanding, showing that they read some, but did not dig very deep Showed that they looked into the two communities and synthesized how they each encourage (or didnt) good design Synthesized good/bad design outcomes via their own exploration of the topic (beyond links given here in the activity)
Finds software design artifacts Did not read artifacts linked to here in activity Read artifacts mentioned here, but did not seek out any of their own Read artifacts mentioned here, and found some of their own, but did not utilize them profoundly in their write-up Found their own new artifacts, explained how they found them, and wove them into their papers findings
Forms their own position on what is good software design Did not attempt to express their position Minimal expression; For example, they say that a lack of artifacts and documentation is bad, but they dont give details; Too generalized Well-formed opinion that is backed by details; Being "right" doesn't matter as much as reasoning behind why Well-formed opinions that are expertly backed by myriads of URLs to proof as to why they are right
Gains a method of approaching new projects Did not attempt to learn a wider pattern; Failed above other objectives Answered the questions matter-of-fact and did not expand on their searches into each community Explicitly expressed how they might re-use this lesson to the particular context of software design research Expressed in their essay how this method could be used in any open source project exploration, not just software design

Comments

  • What should the instructor know before using this activity?
  • Encourage students to find new design and architecture information. They should be scouring the sites wiki's, code, documentation, etc.
  • The links given to students should be a guide - they are not exhaustive.
  • Because these communities are large, their resources will grow and change over time. What was there one semester, may not be there another semester. Or, they may add design documentation that formerly was not there.
  • What are some likely difficulties that an instructor may encounter using this activity?
  • This activity asks for a lot of reading and writing. Certain students may not excel at this, or will take considerably longer to finish it than with other students.
  • Additionally, this activity asks student to form and communicate their own opinion. It may take prodding for certain students to feel comfortable with doing this.


Additional Information

ACM BoK
Area & Unit(s)

SDF/Algorithms and Design; SE/Software Design

ACM BoK
Topic(s)

Fundamental design concepts and principles; Structural and behavioral models of software designs; System design principles; Software architecture concepts and standard architectures; Measurement and analysis of design quality

Difficulty

easy to medium

Estimated Time
to Complete

3-8 hours (different students will vary wildly b/c of their reading/writing/deduction skills)

Environment /
Materials
  • Internet access
  • Word processor - Some way to write their essay and answers
Author(s)

Nick Yeates

Source
License

This work is licensed under a Creative Commons Attribution 4.0 International License

CC-BY.png


Suggestions for Open Source Community:

  • Suggestions for an open source community member who is working in conjunction with the instructor.
  • Review with students what software design artifacts and processes exist in your project. Where does there need improvement? Be honest with them. Many opensource projects don't have the resources for this, or design is handled in other ways.
  • Brainstorm with students on how they could help to improve your projects software design and architecture documents, diagrams, processes and artifacts. Maybe the students can put together high-level architecture diagrams that are friendly to new community developers.


Appendix

Note: Can be removed later, or kept as a resource to teaches looking into other communities.

Potential communities to look into:


Background Readings

  • http://stackoverflow.com/questions/704855/software-design-vs-software-architecture
  • http://www.openu.ac.il/personal_sites/download/galezer/SoftwareDesign.pdf
    • This paper describes how they had to get students to re-think how they write code. The students needed to think more outside of the syntax of the actual language, and more toward software design / repeatable design patterns that dont depend on the coding language.
    • I am looking at this paper and thinking about the various tasks or activities that they show were done in their classroom. I may be able to use these ideas.
    • “It should be re-emphasized that practical programming does not play a central role in the unit. At the end of the year students and teachers realized that programming in itself is not the main goal.”
Retrieved from "http://foss2serve.org/index.php?title=Software_Design_Architecture_Comparison&oldid=12673"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox