Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

SickBeard System Design: Component and Connector View, Class Diagram, and Viewtypes, Study Guides, Projects, Research of Architecture

An overview of the SickBeard system design, focusing on the Component and Connector View and Class Diagram. It also introduces the concept of Viewtypes, specifically Modules, Interfaces, and Allocation. The Component and Connector View explains the internal workings of SickBeard, including interfaces, data flows, variability, and architecture. The Class Diagram illustrates the relationships between different classes in the system. Viewtypes are essential design artifacts that help understand the system's structure, interaction with other systems, and hardware components.

What you will learn

  • What are the key components of the SickBeard system and how do they interact?
  • What are Viewtypes, and how do they contribute to understanding the SickBeard system design?
  • How does the Class Diagram illustrate the relationships between different classes in the SickBeard system?

Typology: Study Guides, Projects, Research

2021/2022

Uploaded on 09/27/2022

thimothy
thimothy 🇬🇧

4

(12)

217 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1. Introduction ..................................................................................................................... 1!
2. Background ..................................................................................................................... 1!
3. Functional Requirements ................................................................................................ 1!
4. Quality Attributes ............................................................................................................ 2!
5. Patterns and Tactics ........................................................................................................ 2!
6. Views .............................................................................................................................. 2!
A. Component and Connector View ............................................................................... 2!
1. Elements .................................................................................................................. 3!
2. Relations ................................................................................................................. 4!
3. Context .................................................................................................................... 4!
4. Variability ............................................................................................................... 4!
5. Architecture ............................................................................................................. 4!
B. Module View .............................................................................................................. 4!
1. Elements .................................................................................................................. 5!
2. Context .................................................................................................................... 5!
3. Variability ............................................................................................................... 5!
4. Architecture ............................................................................................................. 5!
C. Allocation View ......................................................................................................... 5!
1. Elements .................................................................................................................. 5!
2. Interfaces ................................................................................................................. 6!
3. Context .................................................................................................................... 7!
4. Variability ............................................................................................................... 7!
5. Architecture ............................................................................................................. 7!
7. Framework ...................................................................................................................... 9!
8. Acknowledgements ......................................................................................................... 9!
9. References ....................................................................................................................... 9!
10. Revision history .......................................................................................................... 10!
11. Appendices .................................................................................................................. 10!
A. Glossary ................................................................................................................... 10!
1. Introduction
<Describe the purpose of the document and give a brief overview. Include a guide for
different types of stakeholders.>
2. Background
<Give a brief statement of the problem and the intended solution. Describe the main
stakeholders and their concerns. Describe any existing systems, especially those that have
interfaces with your system. Include a shortened version the very highest level points
from the Problem Statement, and give a reference to that.>
3. Functional Requirements
<Describe the main functional requirements. You do not need to include all of the use
cases, but a few examples might be helpful, as noted in the Guidelines, above. Refer the
reader to the Requirements Document for more details. Pick at least one use case and
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download SickBeard System Design: Component and Connector View, Class Diagram, and Viewtypes and more Study Guides, Projects, Research Architecture in PDF only on Docsity!

  1. Introduction ..................................................................................................................... 1
  2. Background ..................................................................................................................... 1
  3. Functional Requirements ................................................................................................ 1
  4. Quality Attributes............................................................................................................ 2
  5. Patterns and Tactics ........................................................................................................ 2
  6. Views .............................................................................................................................. 2 A. Component and Connector View ............................................................................... 2 1. Elements.................................................................................................................. 3 2. Relations ................................................................................................................. 4 3. Context .................................................................................................................... 4 4. Variability ............................................................................................................... 4 5. Architecture............................................................................................................. 4 B. Module View .............................................................................................................. 4 1. Elements.................................................................................................................. 5 2. Context .................................................................................................................... 5 3. Variability ............................................................................................................... 5 4. Architecture............................................................................................................. 5 C. Allocation View ......................................................................................................... 5 1. Elements.................................................................................................................. 5 2. Interfaces ................................................................................................................. 6 3. Context .................................................................................................................... 7 4. Variability ............................................................................................................... 7 5. Architecture............................................................................................................. 7
  7. Framework ...................................................................................................................... 9
  8. Acknowledgements ......................................................................................................... 9
  9. References ....................................................................................................................... 9
  10. Revision history .......................................................................................................... 10
  11. Appendices.................................................................................................................. 10 A. Glossary ................................................................................................................... 10

1. Introduction

2. Background

<Give a brief statement of the problem and the intended solution. Describe the main stakeholders and their concerns. Describe any existing systems, especially those that have interfaces with your system. Include a shortened version the very highest level points from the Problem Statement, and give a reference to that.>

3. Functional Requirements

<Describe the main functional requirements. You do not need to include all of the use cases, but a few examples might be helpful, as noted in the Guidelines, above. Refer the reader to the Requirements Document for more details. Pick at least one use case and

detail it with design information, as a prime example of how the system will work doing its main function.>

4. Quality Attributes

<Use the scenario table format to describe all of the quality attributes that must be included in the final system. Rank these architectural drivers, in terms of their importance. As noted in the guidelines, above, the most important of these quality attributes, for the system to succeed, should be given more space.>

5. Patterns and Tactics

< Describe the tactics used to achieve each quality attribute. Describe any patterns that are used to package tactics. If you don't have any patterns, describe how different forces influence the choice of tactics. You should give the most attention to what is believed to be the most important of these quality attributes – how to achieve that. This section especially should record your rationale for the design. It should say what alternatives you considered, and why you chose the one you did. Your instructors will be paying special attention to what you say here! If you used “patterns” in your system, in the sense of the Gang-of-Four patterns, and want to elaborate on those, that probably should go in Section 7, as a part of your Framework discussion.>

6. Views

A. Component and Connector View

information (including actors, summary, credits, etc...) for a given show. The DataSorter element provides a way to take a set of TV episodes or shows and apply a logical ordering to them. The NetworkSort element does the same but relies on the TVDB api for information. The ShowList element takes data from the sorter, and formats it so it can be displayed in a logical order to the user. The ListView element provides the formatting for the list of shows, the ShowList.

2. Relations The relations exist in the ShowProcessor and ViewBuilder. The filters in these elements depend on each other to pass data throughout the system. Similar to a Pipe and filter model. 3. Context The views show the high level breakdown of software components internal to SickBeard, in terms of data flows. This is an alternative to an OO view. It is lower level than an allocation view, yet a higher level then code. 4. Variability Altering the behavior of an existing filter, or creating new filters and inserting them into the internal workings of SickBeard is how to exercise any variation points in the system. 5. Architecture SickBeard started with one core functionality, and as it added more functionality it extended its existing set of filters to do more with regards to the TVDB API, file management, etc.

B. Module View

Above is the class diagram for SickBeard. The diagram shows how the different classes in our system interact with each other.

1. Elements Our system is made up of many different classes, and controlled through one main class called Sickbeard. The main class is used to control the web interface, however it knows very little about how the system actually works. In order to get the implementation details it makes class to all of the different classes. The system functionality is split up into many different classes in order to hid different parts of the system from each other. This makes working on and individual piece of the system much easier to understand, because the developer does not have to worry about the implementation details of the other parts. The system works by first loading the data stored in the database and accessed through the DB object, into tv show and tv episode objects. After loading the data, the system checks each show to find upcoming episodes, if one is found it is the added to a queue for processing. While processing the queue it will log any errors it finds in the data, as well as send notifications to the user about the upcoming episodes. 2. Context The diagram purposefully does not show how the system interacts with external services because this interaction is shown in the allocation view. 3. Variability In order to exercise any variation points in the system, a developer can simply create new classes to be used by the main controlling class. These new classes can incorporate new features, or simply come about from a refactoring of the old system. 4. Architecture This design came to be through a long process of trail and error. When the system was first designed it did not have separate classes for different functionality. As the system became larger it was apparent that these separate classes were necessary to help new developers work with the system, as well as help current developers keep a separation of concerns.

C. Allocation View

1. Elements Hardware Client

Data Types TVDBAPI Class This is the API class that we can make calls against. There are several methods that allow us to query multiple pieces of information such as seasons, series or individual episodes. It also provides an easy interface for obtaining images. Exceptions There are very few exceptions in this system, as this is the nature of the system’s design. We are using the model that exceptions should be used for exceptional circumstances. Variability There is minimal variability due the lack of need for variability. The API provides all the data in an easy to access form so therefore we don’t need different forms of this. Quality Attributes SickBeard provides a clean pythonic interface that any python programmer can pick up and understand. This is awesome as it was very easy for each of our developers picked it up right away. Element Requirements The system requires it’s own database and theTVDB webserver. These are the only two software requirements in order to run SickBeard successfully. Rational and Design Issues TheTVDB existed before the API did and thus was written to bridge the connection between TheTVDB and any python interface.

3. Context This system’s Environment is the Hardware and Internet. These environmental elements are both required for proper operation, although SickBeard can run without Internet in a limp mode. Many of the functions are disabled in limp mode, but the user is notified about the problem. 4. Variability In order to provide an easy implementation, we need to minimize our variation. We do this to keep items succinct and simple to keep variation down. 5. Architecture The overall structure is built on existing web service technologies. The overall structure of the program will be dead simple for anyone to pickup. It also employs web standard API technology implementations so anyone familiar with standard web API technologies will be familiar with the system.

<These are the pictures and their explanations. Provide an introductory paragraph listing the purpose of each view. What kinds of views do you need? See the Viewtypes discussion, below. Include each view as a lettered subsection of this section. That is, the first view should be 6.A, the second should be 6.B, etc. Each view should have all of the following subsections:

  1. Primary presentation – this will often be a diagram
  2. Element catalog A. Elements - brief description of each B. Relations - brief description of each C. Interfaces - for views that include them 1) Interface identity - unique name 2) Resources provided - syntax and semantics 3) Locally defined data types - if used 4) Exception definitions - including handling 5) Variability provided - for product lines 6) Quality attribute characteristics - what is provided? 7) Element requirements - names of required items, assumptions 8) Rationale and design issues - why these choices 9) Usage guide - protocols
  3. Context diagram -- how the system relates to its environment
  4. Variability guide – how to exercise any variation points
  5. Architecture background – why the design reflected in the view came to be
  6. Glossary of terms used - alternatively, you may place these in a separate glossary for the whole document
  7. Other information - if needed Viewtypes: There are typically 3 kinds of views you need to show, which translates to 3 or more views in this high-level document: Modules – These are “design time entities” of your system. The structure of the OO design (or other software design methodology). This is probably the same thing as the “framework” described in the next section. So, Section 7 becomes effectively an extension of the picture and the basic explanation of it given here. Often, there are multiple versions of this viewtype – say, a UML class diagram showing OO decomposition, generalization and uses; and then a view of the software “layers” in the system, perhaps showing how your software uses third-party software. Component-and-connector (C&C) – This shows the “run time entities” of your system. How is it all supposed to work? For example, how does a “message” or “transaction” get through your system? Or, how does the main use case happen, in terms of pieces of the system interacting? The explanation should be “stream of execution.” Often, your system’s “style” comes out the most in this figure, and readers can see the pipes-and-filters, or client-server design. Interfaces to

10. Revision history

11. Appendices

A. Glossary

API .........................................Application Programming Interface. A standardized set of methods provided for developers to use when connecting to the application. In the context of the TVDB, refers to a set of Web-based data connections that return information about TV shows. SickBeard ..............................An open-source application that interfaces with the TVDB in order to provide an interface into a local TV collection with information about each show. TVDB ....................................Television Database. A freely available collection of information