SAD FOR BUG BASE

8/7/2019 SAD FOR BUG BASE

1/19

EXPERIMENT NO: 1

Software Architecture

DocumentOn Bug Base

Bug base is a web application used for managing and reporting bugs. It is a tool used formanaging bug reports.


2/19

Table of Contents

1.Introduction

1.1 Purpose

1.2 Scope

1.3 Definition, Acronym and Abbrevation

1.4 References

2. Architectural Representation

3. Architectural Goals and Constraints

4. Use-case View

4.1 Architecturally Significant Use-Cases

5. Logical View

5.1 Class Diagram

5.2 Object Diagram

6.Process View

6.1 State-Chart Diagram

6.2 Activity Diagram

6.3 Sequence Diagram

6.4 Colloboration diagram

7. Implementation View

7.1 Component Diagram

8. Deployment View

9. Size and Performance

10. Quality


3/19

Software Architecture Document

1. Introduction

1.1 Purpose

This document provides a comprehensive architectural overview of the system, using anumber of different architectural views to depict different aspects of the system. It is intended to

capture and convey the significant architectural decisions which have been made on the system.

1.2 Scope

This Software Architecture Document provides an architectural overview of The Bug Base.The Bug Base allows you and your team members to collaboratively file, change, and report on

bugs through a web interface. The Bug Base application allows you to carry out four important

tasks: filing bugs, changing bugs,reporting about bugs, and application maintenance.It basicallyuses a role-based security mechanism.

This Document has been generated directly from the Bug Base Analysis & Design Model

implemented in IBM Rational Software Architect. The majority of the sections have beenextracted from the Rose Model using SoDA and the Software Architecture Document template.

1.3Definitions, Acronyms and Abbreviations

y ASP-active server pagey PHP - Hypertext Processor scripting languagey MySQL relational database management system (RDBMS)y SAD - Software Architecture Documeny RUP - Rational Unified Procesy UML Unified Modeling Languagey Fig - Figurey Tester -A tester can only file new bugs, change his or her own bugs, or add comments to

existing bugs.

y Developer - A developer can perform the same actions as a tester, but in addition adeveloper can also change existing bugs and change their status.

y Manager -A manager has the same rights as a developer,but can also use the reportingfunctionality.

y Administrator - An administrator has the same permissions as a tester has. However, anadministrator can also access the maintenance section to manage applications, features,and members.


4/19

1.4 References

Applicable references are:

[RUPRSA]: Developing a J2EE Architecture with Rational Software Architect using the

Rational Unified Process, IBM DeveloperWorks, Jean-Louis Marchaux,Mars 2005,

http://www-128.ibm.com/developerworks/rational/library/05/0816_Louis/

[KRU41]: The 4+1 view model of software architecture, Philippe Kruchten, November

1995,http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/200

3/Pbk4p1.pdf

[DDA41]: UML overview from developer.com

http://www.developer.com/design/article.php/1553851

2. Architectural Representation

This document details the architecture using the views defined in the 4+1 model [KRU41],

but using the RUP naming convention. The views used to document the Bug Base applicationare:

y Logical viewAudience: Designers.

Area: Functional Requirements: describes the design's object model. Also describes the

most important use-case realizations.

Related Artifacts: Design model

y Process viewAudience: Integrators.


5/19

Area: Non-functional requirements: describes the design's concurrency and

synchronization aspects.

Related Artifacts: Dynamic model, state-charts, activities

y Implementation viewAudience: Programmers.

Area: Software components: describes the layers and subsystems of the application.

Related Artifacts: Implementation model, components

y Deployment viewAudience: Deployment managers.

Area: Topology: describes the mapping of the software onto the hardware and shows the

system's distributed aspects.

Related Artifacts: Deployment model.

y Use Case viewAudience: all the stakeholders of the system, including the end-users.

Area: describes the set of scenarios and/or use cases that represent some significant,

central functionality of the system.

Related Artifacts : Use-Case Model, Use-Case documents

3. Architectural Goals and Constraints

There are some key requirements and system constraints that have a significant bearing on the

architecture. They are:

1. The Bug Base application allows you to carry out four important tasks: filing bugs,changing bugs,reporting about bugs, and application maintenance.


6/19

2. The role-based security mechanism implemented in the Bug Base grants access to each ofthese features to the roles defined in the system.

3. Each user should be assigned to at least one role so they can log in and perform one ofthese tasks.

4. A tester can only file new bugs, change his or her own bugs, or add comments to existingbugs.5. A developer can perform the same actions as a tester, but in addition a developer canalso change existing bugs and change their status.

6. A manager has the same rights as a developer, but can also use the reportingfunctionality.

7. An administrator has the same permissions a tester has. However, an administrator canalso access the maintenance section to manage applications, features, and members.

4. Use-Case View

A description of the use-case view of the software architecture. The Use Case View is importantinput to the selection of the set of scenarios and/or use cases that are the focus of an iteration. It

describes the set of scenarios and/or use cases that represent some significant, centralfunctionality. It also describes the set of scenarios and/or use cases that have a substantial

architectural coverage (that exercise many architectural elements) or that stress or illustrate aspecific, delicate point of the architecture.

The Bug Base use cases are:

File bug Remove bug Manage bug Add comment Bug status

These use cases are initiated by the Tester, Manager, Developer and Administrator.

4.1 Architecturally-Significant Use Cases


7/19

Fig : USE-CASE DIAGRAMFOR BUG BASE

5. Logical View

A description of the logical view of the architecture. Describes the most important classes,

their organization in service packages and subsystems, and the organization of these subsystemsinto layers. Also describes the most important use-case realizations, for example, the dynamic

aspects of the architecture.

5.1 Class diagrams: Class diagram may be included to illustrate the relationships between

architecturally significant classes, subsystems, packages and layers.

The Bug Base is designed as a three-layered architecture, which means that presentation,business logic, and data access are each placed in different layers ortiers.


8/19

The presentation layer of The Bug Base digs into each of the important pages and shows youhow they interact with each other and use the classes in the business layer. The presentation layer

consists of a number of .aspx pages and .ascx user controls that use ASP.NET server controls.These pages talk to classes defined in the business layer that in turn talk to the data access layer

to get information in and from the database.

Fig : CLASS DIAGRAMFOR BUG BASE

The following table discusses each table in the database and its intended purpose:


9/19

Table Description

Application Holds a list with all the applications you can file bugs against. The

column is Active, determines whether the application is still in use.

aspnet_Users This table is added by the aspnet_regsql.exe tool when you enable thedatabase for Membership and Roles. It holds the user accounts for the

Bug Base application. The UserId, a GUID, is used to link other

tables to this table.

Bug The logged bugs are stored in this table. Besides a Title, a

Description, and the date the bug was created and updated, this table

largely consists of foreign keys pointing to domain listtables.

Comment Holds comments that users can add to existing bugs. The

CreateMemberId has a link to the aspnet_Users table to keep track of

who added the comment.

Feature Features are the main parts that make up your application. A bug

shouldbe logged against a specific feature, to make it clearer where

the bug occurs and whos responsible for it. A feature is always tied

to an application, so the Feature table has an ApplicationId column

that points back to the Application table.

Frequency The frequency of a bug defines how often, or by how many users, a

bug will be encountered. This table holds a list with possible optionsthat the user can choose from.

MemberApplication Users should not be able to log bugs against any arbitrary application.

An Administrator can assign members to a specific application

through the web application. This assignment is stored in the junction

table Member-Application.

Reproducibility The reproducibility of a bug defines whether a bug is reproducible at

all, and if so, how often. Just as the Frequency and Feature tables, this

is a domain list table that stores the description for each item with a

primary key. This key is then used as a foreign key in the Bug table.

Severity The severity describes the impact of the bug. This domain list table

holds the various options for this bug property.


10/19

Status This table holds a list with possible status options for a bug. The

ClosesBug column determines whether the bug becomes inactive with

a specific status. This is the case for a status such as Deferred, Closed,

or Not a Bug.

5.2 Object diagram: An object is an instance of a class. This essentially means that an object

represents the state of a class at a given point of time while the system is running. The objectdiagram captures the state of different classes in the system and their relationships or

associations at a given point of time.

Fig : OBJECT DIAGRAMFOR BUG BASE


11/19

6. Process View

The dynamic behavior of a system can be seen using the process view. The different diagrams

such as the state diagram, activity diagram, sequence diagram, and collaboration diagram are

used in this view. A description of the process view of the architecture. Describes the tasks

(processes and threads) involved in the system's execution, their interactions and configurations.Also describes the allocation of objects and classes to tasks.

6.1 State-Chart diagram: A state diagram represents the different states that objects in thesystem undergo during their life cycle. Objects in the system change states in response to events.

In addition to this, a state diagram also captures the transition of the object's state from an initialstate to a final state in response to events affecting the system.

Here in this case, the object in the system is the Bug. The various stages through which the bugis initially filled and then eventually removed is depicted through the state chart diagram.

Fig : STATE CHART DIAGRAMFOR BUG BASE


12/19

6.1.1Main: In the main the bug is filed, either a new bug or an existing bug.

6.1.2 Existing bug : In this state, it is detected whether the bug is an existing one or new.

6.1.3 Filling new bug: In this state, a new bug is filled.

6.1.4 Checking the severity : In this state, the severity of the bug is made known.

6.1.5 Reporting bug: In the state, the filed bug is reported to the other users.

6.1.6 Changing status: Here the status of the bug is changed after any kind of modification.

6.1.7 Removing bug: The bug which is filed is removed.

6.1.8 Maintenance: Maintenance of application.

6.2 Activity diagram: The process flows in the system are captured in the activity diagram.

Similar to a state diagram, an activity diagram also consists of activities, actions, transitions,initial and final states, and guard conditions.


13/19

Fig : ACTIVITY DIAGRAMFOR BUG BASE

6.3 Sequence diagram: A sequence diagram represents the interaction between different

objects in the system. The important aspect of a sequence diagram is that it is time-ordered and

the exact sequence of the interactions between the objects is represented step by step. Different

objects in the sequence diagram interact with each other by passing "messages". As the bug base

application uses a role based mechanism, allowing to determine who in the team will perform


14/19

which operation.Here in this case, the tester, developer, manager and the administrator performs

different functions on the bug as seen in the activity diagram.

Fig : SEQUENCE DIAGRAMFOR BUG BASE


15/19

6.4 Collaboration diagram: A collaboration diagram groups together the interactions between

different objects. The interactions are listed as numbered interactions that help to trace the

sequence of the interactions. The collaboration diagram helps to identify all the possible

interactions that each object has with other objects.

Fig : COLLABORATION DIAGRAM OF BUG BASE

7. IMPLEMENTATION VIEW

The Implementation view depicts the physical composition of the implementation in terms of

Implementation Subsystems, and Implementation Elements (directories and files, including

source code, data, and executable files).

Usually, the layers of the Implementation view do fit the layering defined in the Logical view


16/19

7.1 Component diagram: The component diagram represents the high-level parts that make up

the system. This diagram depicts, at a high level, what components form part of the system and

how they are interrelated. A component diagram depicts the components culled after the system

has undergone the development or construction phase.

Fig:COMPONENT DIAGRAMFOR BUG BASE

7.1.1 Presentation Layer: It includes a varieties of pages which helps in interaction withthe bussieness layer.


17/19

7.1.2 Bussieness layer : It consist of eight classes and an enumeration namely: Bug,BugManager, Bug Comparer, List Manager, Member Manager, Comment Manager.

It is responsible for all the actions on the Bug.

7.1.3 Data Acess Layer: This layer in the bug base is designed to work with SQL Server.The different classes in this layer is BugManagerDB, ListManagerDB,

CommandManagerDB, MemberManagerDB. Methods in this class talk directly to

the database.

8. Deployment View

A description of the deployment view of the architecture . Describes the various physical nodesfor the most typical platform configurations. Also describes the allocation of tasks (from the

Process View) to the physical nodes.

This section is organized by physical network configuration; each such configuration is

illustrated by a deployment diagram, followed by a mapping of processes to each processor.

Fig: DEPLOYMENT DIAGRAMFOR BUG BASE


18/19

9. Size and Performancey Size:

The size of the database increases day by day,increasing the load on the databaseback up and data maintenance activity.

y Performance:User authentication with the Bugbase must be under 10 seconds.

10.Qualityy Scalability:

It is scalable as it is a web-enabled project and data are stored in a single database.

y Reliability/Availability:Reliability/Availability will be addressed through the .Net framework and the

server speed.

Targeted availability is 20/7: 20 hours a day, 7 days a week.

The time left (4 hours) is reserved for any maintenance activities

y Security:The system employs two types of checks and control:

Client-side validaton- using JSScript and Tab-indexes

Server-Side validation- using various constraints and access control mechanism.


19/19

.

Documents

SAD FOR BUG BASE