Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
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.