SFWRTECH 4SA3 - Software Architecture - Project
Overview
The project component of the course will involve proposing, designing, documenting,
implementing and presenting a software architecture across 4 project milestones over the
course of the term. The project is an opportunity for you to demonstrate the most core learning
objectives in this course across these milestones.
The software and architecture itself must meet the requirements listed in this document, but
otherwise the application idea, design, and implementation technologies are all up to you. As
such, this is also an opportunity to receive academic credit for building your software
development portfolio while creating something you’re passionate about! Software development
portfolios are critically important to modern job seekers... typically made up of a collection of
projects hosted on GitHub, a portfolio demonstrates your practical skills to the world.
Learning Objectives
• Design and document a software architecture using the 4+1 view model.
• Implement a software architecture, including design patterns.
• Present a software architecture design.
Project Scope
It’s very important to keep in mind scope when working on this project. If you attempt to build
something more complex than required, and/or with too many technologies you are unfamiliar
with, you may run out of time and/or do more work than necessary. Your project only needs to
conform to the minimum requirements, and no more than that. If you would like to create
something more ambitious, perhaps because you are an experienced developer or feel
comfortable investing the time, this is up to you, but please be very mindful of time.
The project is focused on software architecture, as such keep in mind the following to save
yourself time:
• User interface design will not play a factor in marks, beyond it being possible to use the
application. A text-based command-line interface is suitable.
• Do not worry about validating input from a user, 3rd party service or other source of
input... you can assume the user inputs data correctly, and any data provided from any
other source is correct.
• Functionalities need to exist in that they can be carried out, but they do not need to be
commercial quality or built with a rich feature set. The expectation is a barebones
prototype that demonstrates the functionality in a minimal way.
o e.g. generating a report does not need to produce a well-designed PDF, it can
simply be a table of text output to the command-line.
What you will be marked on is the concepts related to software architecture... correct usage of
design patterns, the 4+1 view model, implementation of the architecture, etc. I will try to
emphasize this difference in-class, but if you are unsure please let me know.
This document will be released before the week 4 class so that you may begin to think about
project ideas, but please do not get too committed to any idea until after the week 6 class and
completing your project proposal (by then we will have covered many design patterns and other
necessary concepts).
Please see the accompanying project ideas document in the Avenue to Learn course shell for
project ideas that would likely make the foundation for a suitable application.
Overall Requirements
Your project must meet the following requirements:
• Read and write data using a cloud database.
o Choose whatever you think makes sense: Redis, MySQL, PostgreSQL, etc.
• Use a third-party web service.
o This might include RESTful APIs, payment solutions (Stripe, etc), Map services
(Google Maps, etc.), etc.
• Incorporate 3 software design patterns in a meaningful way.
o At least one creational pattern or behavioral pattern.
o You are not limited to design patterns discussed in this course. At least one
design pattern should be a design pattern we did not cover or mention in-class.
▪ But do provide a very clear citation for other design patterns that you use,
both in the code where the design pattern is used (i.e. with a comment)
and in your architecture design document.
o Architectural styles like client-server, component-based design, object-oriented,
etc, do not count towards the 3 design patterns.
o Architectural patterns like MVC can count towards the 3 design patterns.
o You have to implement the pattern, using the pattern as part of a pre-existing
library or language does not count towards the 3 design patterns.
• The software you create must carry out some set of functionalities for a user or groups of
users. The exact number is up to you, but you should have at least two functionalities,
and no more functionalities than is required to satisfy the rest of these requirements is
expected. By milestone #2 you should be able to list these as a small set of
requirements for your project. Functionalities might include:
o Managing a collection of data (read, write, update, destroy operations)
o Generating reports about data, analyzing data, searching data, accessing data
(e.g. via a web API), etc.
We will be going over examples in-class of using a cloud database and a web-service with
Python (both of which can be done with a few lines of code). We will be going over several
examples of using and implementing design patterns in Python in-class. My expectation is that
by weeks 6-8, even if you are less experienced with programming you will have a strong set of
examples of the above ideas to help you implement your own project.
As with anything, the project does need to be your own original work, and so your
solution shouldn’t be made up of slightly re-worked versions of code created in-class, it
should be substantially different. If there is any confusion about this, then I would
suggest NOT using the example code posted on Avenue to Learn at all, e.g. by using
different design patterns entirely. To fulfill the requirement of 3 meaningful design
patterns, you would need to implement 3 yourself in a clearly original way. A reminder
you are not limited to using design patterns discussed in the course.
Milestone Re-Submit Due Date
Feedback and a grade will be provided to students who submit a milestone before the initial
deadline. Students will have 7 days from the date of this initial feedback to resubmit the
milestone. Students will be awarded the higher overall milestone grade of the two submissions
(i.e. your mark can only go up by re-submitting the milestone).
Project Milestone #1 - Proposal
Initial Due Date: Monday October 23rd at 11:59pm
Weight: 2%
Requirements:
Propose an application that will be designed, documented, implemented and presented during
the subsequent project milestones. The proposal should include the following:
• Proposed software name.
• A brief description of the purpose of your software (ideally one paragraph or less).
• Describe the target audience of the software.
• Describe the functionalities that users will be allowed to perform, and/or the features of
the software. i.e. what will your application do
o You can add or remove from this list later, but your application should not change
entirely from this outline either.
• Describe where you see opportunities for using design patterns in desirable ways.
o At least 2 potential design patterns should be identified at this point.
o This is not a commitment or a requirement for your application, you will not be
held to these expectations on subsequent milestones. But you should see
opportunities to use design patterns and/or architectural styles in desirable ways
and identify them in the proposal (a bulleted list or table would suffice).
• Describe the technologies you intend to use to build the software.
o Programming languages, third-party services, databases, etc.
o Make sure to specify the cloud database and third-party web service you intend
on using.
o Describe the role these technologies will play.
o Again, this is not set in stone, you can change these later if need be, but you
should have a good idea at this point.
Your proposal should be no more than 2 pages in length.
The proposal is not a detailed formal requirements document, it is intended to outline what you
are intending to create in the ways listed above. The project purpose and general idea as to
what it does should not change after this proposal and the feedback you receive, though the
precise tasks, initial design approach, and technology choices may change in subsequent
milestones.
You will receive feedback on your proposed idea as soon as possible after the due date, as
such this is an important assessment to submit on time. In particular, you may be given help to
scope your project accordingly... it may be very strongly suggested that you either drop ideas or
keep them as “stretch goals” (i.e. to do only if you have time), or you may be given ideas from
which to choose from in order to ensure your project does meet the minimum project scope.
Submission:
Upload the document (PDF format) to the dropbox on Avenue.
Marking scheme:
Grade Definition
Unsatisfactory The proposal is fundamentally incorrect, incomplete, and/or contains
at least one critically important mistake, or the proposal does not
demonstrate a reasonable understanding of the material.
Satisfactory The proposal is overall correct and largely complete, it may contain
multiple minor mistakes or even a major mistake, and the proposal
does demonstrate a reasonable understanding of the material.
In the case of a grade of unsatisfactory, specific reference will be made to areas of the proposal
that are incorrect, incomplete, contain mistake(s), or demonstrate a lack of understanding of the
material. For the purposes of a letter grade, a grade of satisfactory translates to a grade of
100% on the milestone and a grade of unsatisfactory translates to a grade of 0% on the
milestone.
Project Milestone #2 – 4+1 View Model + Database Connection
Initial Due Date: Monday November 6th at 11:59pm
Weight: 9%
Requirements:
Submit a software architecture document that uses the 4+1 View Model to document your
application’s software architecture. Your document must have the following sections completed
for this milestone:
• Project purpose and audience
o Include these verbatim from milestone #1, with any revisions you feel necessary.
• Requirements
o Present at least 5 requirements in a table (functional and/or non-functional). The
requirements should precisely define your application’s functionalities.
• Scenario Viewpoint
o Should have at least one diagram. Include any text you feel is necessary to
explain the diagram or what is important in the viewpoint.
• Physical Viewpoint
o Should have at least one diagram. Include any text you feel is necessary to
explain the diagram or what is important in the viewpoint.
You do not need any additional sections typically found in a software architecture document
(e.g. constraints, risks, acronym section, etc.), but if you would like to include any of these you
are free to do so. Do not document the other 3 viewpoints in the 4+1 View Model, these are left
for the next milestone. At this milestone, it is still OK if you need to change precise
requirements and/or the architecture design in future milestones, but the number of changes
should be low and they should not change the nature of your application entirely (e.g. switching
which cloud database you use is OK, adding/removing a requirement is also OK).
Submit code that demonstrates you can access and use the cloud database you have chosen.
The code doesn’t have to do anything more than connect to the database and either retrieve or
manipulate some data in the database.
Submission:
Upload the document (PDF format) to the dropbox on Avenue.
Marking scheme:
Grade Definition
Unsatisfactory The documentation and code are fundamentally incorrect,
incomplete, and/or contains at least one critically important mistake,
or the documentation and code do not demonstrate a reasonable
understanding of the material.
Satisfactory The documentation and code are overall correct and largely
complete, they may contain multiple minor mistakes or even a major
mistake, and the documentation and code demonstrate a reasonable
understanding of the material.
In the case of a grade of unsatisfactory, specific reference will be made to areas of the
documentation and/or code that are incorrect, incomplete, contain mistake(s), or demonstrate a
lack of understanding of the material. For the purposes of a letter grade, a grade of satisfactory
translates to a grade of 100% on the milestone and a grade of unsatisfactory translates to a
grade of 0% on the milestone.
Project Milestone #3 – 4+1 View Model
Initial Due Date: Monday November 20th at 11:59pm
Weight: 9%
Requirements:
Update your software architecture document from Milestone #2 to include the following sections
related to the 4+1 View Model.
• Development Viewpoint
o Should have at least one UML diagram. Include any text you feel is necessary to
explain the diagram or what is important in the viewpoint.
• Logical Viewpoint
o Should have at least one UML diagram. Include any text you feel is necessary to
explain the diagram or what is important in the viewpoint.
• Process Viewpoint
o Should have at least one UML diagram. Include any text you feel is necessary to
explain the diagram or what is important in the viewpoint.
If you have made any changes to your software’s requirements, physical viewpoint or scenario
viewpoint after your feedback from project milestone #2, update these in this document. At this
point the software architecture document should very much reflect the final system that you
implement. However, it is still OK if you need to change precise requirements and/or the
architecture design in final milestone, but the number of changes should be low and they should
not change the nature of your application entirely (e.g. switching which cloud database you use
is OK, adding/removing a requirement is also OK).
Submit code that demonstrates you can access and use the web API that you have chosen.
The code doesn’t have to do anything more than fetch some data from the web API or somehow
otherwise demonstrate its basic usage.
If you would like to submit an incomplete draft version of your project implementation for
feedback as part of this milestone, it will be accepted, and you will be given what feedback is
possible. Please leave a comment in your Avene submission indicating you have done so if this
is the case. This is optional and will not be considered when awarding a grade of unsatisfactory
or satisfactory, it is an option intended only to help you out.
Submission:
Upload the document (PDF format) to the dropbox on Avenue.
Marking rubric:
Grade Definition
Unsatisfactory The documentation and code are fundamentally incorrect,
incomplete, and/or contains at least one critically important mistake,
or the documentation and code do not demonstrate a reasonable
understanding of the material.
Satisfactory The documentation and code are overall correct and largely
complete, they may contain multiple minor mistakes or even a major
mistake, and the documentation and code demonstrate a reasonable
understanding of the material.
In the case of a grade of satisfactory, specific reference will be made to areas of the
documentation and/or code that are incorrect, incomplete, contain mistake(s), or demonstrate a
lack of understanding of the material. For the purposes of a letter grade, a grade of satisfactory
translates to a grade of 100% on the milestone and a grade of unsatisfactory translates to a
grade of 0% on the milestone.
Project Milestone #4 – Implementation + Video Presentation
Initial Due Date: Monday December 4th at 11:59pm
Weight: 20%
Requirements:
Submit the implementation of your project (i.e. the code source files).
• Use comments to document the most important or any potentially unclear aspects of
your implementation.
• The implementation should meet the overall project requirements in terms of design
patterns, database, third-party service, etc.
• Reasonably good coding practices should be followed.
o i.e. design patterns are used, so the implementation shouldn’t be spaghetti code.
These points are optional:
• If you have developed a web application and have hosted it anywhere, please feel free
to include a link to your application in the comments.
• If it is possible for the marker to run your application locally, please feel free to include
quick instructions in the comments as to how to do so (i.e. run python3 main.py).
• It’s highly recommended that you upload your project to a GitHub repository for the
purposes of your portfolio, if you do so, please feel free to include a link in your
comments.
If you have made any changes to your software architecture, re-submit an updated version of
software architecture document from milestone #3. If you have not made any changes, you do
not need to re-submit this document.
Create a 5-10 minute video documenting your project by using screen capture software and
narration. Include the following:
• Discuss the name, purpose, audience and functionalities of your application.
• Demonstrate at least two interesting functionalities of your application.
o Generates a report, accesses some data, analyzes some data, etc.
• Highlight at least two interesting aspects of your architecture design. For each aspect:
o Show and discuss a relevant view in the 4+1 view model including the diagram.
o Show and discuss the relevant implementation. Explain your implementation and
how it connects to your diagrams.
You do not need to demonstrate every functionality of your application. You do not need to
demonstrate all the views of your 4+1 view model. The presentation should have a reasonable
quality delivery (e.g. voice speed, clarity) and reasonable quality audio/video, but we will not be
stringently focused on these points. Your video will be posted on Avenue to Learn so students
can see each other’s projects.
Submission:
Upload a zip file to the dropbox on Avenue containing your project source code. Do not use any
other compression format, only submit a .zip file. Re-submit the software architecture document
as a PDF file if necessary.
Also upload a link to a YouTube video on Avenue to Learn with your presentation. The video
can be set to unlisted so that the general public cannot see the video. You can also submit the
video presentation in .mp4 format (no other format will be accepted).
Marking rubric:
Grade Definition
Unsatisfactory The implementation and presentation are fundamentally incorrect,
incomplete, and/or contains at least one critically important mistake,
or the documentation and code do not demonstrate a reasonable
understanding of the material.
Satisfactory The implementation and presentation are overall correct and largely
complete, they may contain multiple minor mistakes or even a major
mistake, and the implementation and presentation demonstrate a
reasonable understanding of the material.
In the case of a grade of unsatisfactory, specific reference will be made to areas of the
implementation and presentation that are incorrect, incomplete, contain mistake(s), or
demonstrate a lack of understanding of the material. For the purposes of a letter grade, a grade
of satisfactory translates to a grade of 100% on the milestone and a grade of unsatisfactory
translates to a grade of 0% on the milestone.