






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
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
Typology: Study Guides, Projects, Research
1 / 10
This page cannot be seen from the preview
Don't miss anything!
<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.>
<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.>
<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.>
< 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.>
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.
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.
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: