Software Architecture Document

Distributed Team Collaboration Processes II Tool (DTCPII tool)

Ivan Dontsov, Andy Phenix, aureen !ottschaefer

"ersion #$% arch &'#&

Revision History
NOTE: The revision history cycle begins once changes or enhancements are requested after the initial version of the Software Architecture Document has been completed. Date '&(#&(&'#& '&(&&(&'#& '&(&*(&'#& '+('%(&'#& '+(#%(&'#& Version #$' #$# #$& #$+ #$% Description Initial version of SAD for comments by team Some chan)es after !ottschaefer review aureen Author Ivan Dontsov Ivan Dontsov Ivan Dontsov Ivan Dontsov Ivan Dontsov

ore chan)es after team review !eady for the next review ,umber of chan)es after review and online discussions, !eady for final review

SAD DTCPII tool

ii

March 2012

Table of Contents

1. Introduction............................................................................................................................ 1
#$#$ Pur-ose$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ # #$&$ Sco-e$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ # #$+$ Definitions, Acronyms, and Abbreviations$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$& #$%$ !eferences$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ & #$.$ /verview$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &

2. Architectural Representation ...............................................................................................3 3. Architectural oals and Constraints....................................................................................!

+$#$ Security$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ % +$&$ Persistence $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ % +$+$ !eliability(Availability$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ % +$%$ Performance$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ %

!. "se#Case Vie$....................................................................................................................... %
%$#$ Actors$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 0 %$&$ 1se2Case !eali3ations$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 0

%. &o'ical Vie$ .......................................................................................................................... (

.$#$ /verview$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 4

). *rocess Vie$ ......................................................................................................................... + (. ,odule Deco-position Vie$ ...............................................................................................+ +. Data Vie$................................................................................................................................ . .. Deploy-ent Vie$ ................................................................................................................ 11 1/. 0i1e and *erfor-ance.......................................................................................................11 11. Issues and concerns......................................................................................................... 11

SAD DTCPII tool

iii

March 2012

0oft$are Architecture Docu-ent Te-plate

1. Introduction This document -rovides a hi)h level overview and ex-lains the whole architecture of Process S-ecification Tool (PST)$ It is ex-lains how an online user will be able to create and maintain software develo-ment -rocess definitions and includes the underlyin) architecture of the tool$ The document -rovides a hi)h2level descri-tion of the )oals of the architecture, the use cases su--ort by the system and architectural styles and com-onents that have been selected to best achieve the use cases$ This framewor5 then allows for the develo-ment of the desi)n criteria and documents that define the technical and domain standards in detail$ 1.1. *urpose The Software Architecture Document (SAD) -rovides a com-rehensive architectural overview of Distributed Team Collaboration Processes II Tool (DTCPII tool)$ It -resents a number of different architectural views to de-ict different as-ects of the system$ It is intended to ca-ture and convey the si)nificant architectural decisions which have been made on the system$ In order to de-ict the software as accurately as -ossible, the structure of this document is based on the 6%7#8 model view of architecture 9:!1%#;$

The 6%7#8 "iew architecture$

odel allows various sta5eholders to find what they need in the software

1.2. 0cope The sco-e of this SAD is to de-ict the architecture of the Distributed Team Collaboration Processes II Tool (DTCPII tool) online a--lication created by the students of / S<... = &'#'2 &'#&$ This document describes the as-ects of Process S-ecification Tool (PST) desi)n that are considered to be architecturally si)nificant> that is, those elements and behaviors that are most fundamental for )uidin) the construction Process S-ecification Tool and for understandin) this -ro?ect as a whole$ Sta5eholders who re@uire a technical understandin) of Process S-ecification Tool are encoura)ed to start by readin) this document, then reviewin) the Process S-ecification Tool 1 A model, and then by reviewin) the source code$

Software Architecture Document DTCPII tool

arch &'#&

1.3.

Definitions2 Acrony-s2 and Abbreviations Apache = Beb Server A0*.34T 2 icrosoft web -latform

HTT* = Cy-ertext Transfer Protocol *H* # Cy-ertext Processor scri-tin) lan)ua)e ,ono = o-en source im-lementation of Infrastructure icrosoftDs Common Aan)ua)e

,y05& = relational database mana)ement system (!DE S) 666 = Borld Bide Beb 0AD # Software Architecture Document R"* # !ational 1nified Process ",& = 1nified odelin) Aan)ua)e

"ser # This is any user who is re)istered on the website Creator 7*rocess 8$ner9 # This is a user who can create( modify DTCPII out-ut (Process S-ecification) Reader # This user can read(download DTCPII out-ut (Process S-ecification) Ad-inistrator : this user can read, modify and delete any of DTCPII tool Process S-ecification, Process !eview, Process Tem-late and administer other user ri)hts ( roles$ Administrator can dele)ate or share administrative ri)hts to other users in the system$

1.!. 9PP;F

References Pro?ect Pro-osal Software Pro?ect ana)ement Plan

9SP P;F 9S!S;F

Software !e@uirements S-ecification

9 edEi@uitous;F Sam-le SAD, htt-F((medbi@$or)(stdGs-ecs(tech)uidelines(softwarearchitecture$-df 9:!1%#;F The 6%7#8 view model of software architecture, Phili--e :ruchten, ,ovember #HH., htt-F((www+$software$ibm$com(ibmdl(-ub(software(rational(web(white-a-ers(&''+(Pb5%-#$-df 9!1P!SA;F Develo-in) a I&<< Architecture with !ational Software Architect usin) the !ational 1nified ProcessJ, IE Develo-erBor5s, Iean2Aouis arKchaux, ars &''., htt-F((www2 #&*$ibm$com(develo-erwor5s(rational(library('.('*#0GAouis( 1.%. 8vervie$

Software Architecture Document DTCPII tool

&

arch &'#&

In order to fully document all the as-ects of the architecture, the Software Architecture Document contains the followin) subsections$ Section &F describes the use of each view Section +F describes the architectural constraints of the system Section %F describes the functional re@uirements with a si)nificant im-act on the architecture Section .F describes the most im-ortant use2case reali3ation$ Section 0F describes desi)nDs concurrency as-ects Section 4F describes how the system will be de-loyed$ Section *F describes any si)nificant -ersistent element$ Section HF describes any -erformance issues and constraints Section #'F describes any as-ects related to the @uality of service (LoS) attributes 2. Architectural Representation This document details the architecture usin) the views defined in the 6%7#8 model 9:!1%#;, but usin) the !1P namin) convention$ The views used to document the DTCPII tool a--lication areF

"se Case vie$

AudienceF all the sta5eholders of the system, includin) the end2users$ AreaF describes the set of scenarios and(or use cases that re-resent some si)nificant, central functionality of the system$ Describes the actors and use cases for the system, this view -resents the needs of the user and is elaborated further at the desi)n level to describe discrete flows and constraints in more detail$ This domain vocabulary is inde-endent of any -rocessin) model or re-resentational syntax (i$e$ M A)$ Related Artifacts F 1se2Case odel, 1se2Case documents

&o'ical vie$
AudienceF Desi)ners$ AreaF Nunctional !e@uirementsF describes the desi)nOs ob?ect model$ Also describes the most im-ortant use2case reali3ations and business re@uirements of the system$ Related ArtifactsF Desi)n model

*rocess vie$
AudienceF Inte)rators$ AreaF ,on2functional re@uirementsF describes the desi)nOs concurrency and synchroni3ation as-ects$ Related ArtifactsF (no s-ecific artifact)$

,odule Deco-position vie$

AudienceF Pro)rammers$ AreaF Software com-onentsF describes the modules and subsystems of the a--lication$ Related ArtifactsF Im-lementation model, com-onents

Data vie$
Software Architecture Document DTCPII tool +

arch &'#&

AudienceF Data s-ecialists, Database administrators AreaF PersistenceF describes the architecturally si)nificant -ersistent elements in the data model Related ArtifactsF Data model$

Deploy-ent vie$
AudienceF De-loyment mana)ers$ AreaF To-olo)yF describes the ma--in) of the software onto the hardware and shows the systemOs distributed as-ects$ Describes -otential de-loyment structures, by includin) 5nown and antici-ated de-loyment scenarios in the architecture we allow the im-lementers to ma5e certain assum-tions on networ5 -erformance, system interaction and so forth$ Related ArtifactsF De-loyment model$ 3. Architectural oals and Constraints

0erver side DTCPII tool will be hosted on one of PS1 A-ache web servers runnin) on a Ainux -latform, and connectin) to one of the PS1Ds ySLA Database servers$ All communication with client has to com-ly with -ublic CTTPS, TCP(IP communication -rotocol standards$ Client 0ide 1sers will be able to access DTCPII tool only online$ Clients(users are re@uirin) usin) a modern web browser such as o3illa Nirefox #', Internet <x-lorer H, latest versions of Poo)le Chrome or Safari$ 3.1. 0ecurity !eader ri)hts will be )rated to any user accessin) the a--lication2landin) -a)e$ Security for DTCPII tool will be inte)rated with PS1Ds existin) security mechanisms (/DI, or C<CS)$ Administrator and Creator user ri)hts will be assi)ned throu)h the inte)rated with PS1 security$ /nly Administrator user can add or remove other Creators and -erform other administrative tas5s$ 3.2. *ersistence Data -ersistence will be addressed usin) a relational database$ 3.3. Reliability;Availability !eliability(Availability will be addressed throu)h the server -latform su--orted PS1Ds Com-uter Action Team (CAT) Tier #F htt-F((cat$-dx$edu(faculty2staff(cat2su--ort2tiers2an2overview2+$html$ 3.!. *erfor-ance There is no -articular constrains related to system -erformance$ It is antici-ated that the system should res-ond to any re@uest well under standard database and web server scri-t timeouts (&' seconds), also system -erformance can de-end on available hardware, PS1 networ5 and internet connection ca-abilities$ In addition, u-load ( download times

Software Architecture Document DTCPII tool

arch &'#&

can de-end on data si3e which in turn de-ends on user in-ut$ Therefore, actual -erformance can be determined only after system de-loyment and testin)$ !. "se#Case Vie$ This is a list of use2cases that re-resent ma?or functionality of the final system 9S!S;F "iew -rocess s-ecification Ee)in new -rocess s-ecification 1ser Ao)in In-ut Process Com-onents data Publish Process S-ecification Delete -rocess data Delete all data for s-ecified user System delete Process S-ecification download Process Namilies

Software Architecture Document DTCPII tool

arch &'#&

!.1.

Actors

As described in the actorsD corres-ondence dia)ram below, web user could be one of three ty-esF #$ Ad-inistrator has enhanced -rivile)es to view, delete or download Process S-ecifications$ &$ Creator = could create, u-date, delete and download data for -articular Process S-ecification +$ Reader = could view and download data for -articular Process S-ecification %$ 0yste- : Apache 6eb 0erver is the fourth ty-e of actor and is the system itself$ It handles all the -hysical and lo)ical -rocess of the software$ !.2. "se#Case Reali1ations 1se case functionality dia)ram below describes how desi)n elements -rovide the functionalities identified in the si)nificant use2cases$ 1se cases are dis-layed as functionalities for the system$ Nunctionality may enclose more than one use2case$

Software Architecture Document DTCPII tool

arch &'#&

%. &o'ical Vie$ %.1. 8vervie$ DTCPII tool is divided into layers based on the ,2tier architecture 9:!1%#;$

Software Architecture Document DTCPII tool

arch &'#&

The layerin) model of the DTCPII online a--lication is based on a res-onsibility layerin) strate)y that associates each layer with a -articular res-onsibility$ This strate)y has been chosen because it isolates various system res-onsibilities from one another, so that it im-roves both system develo-ment and maintenance$ ). *rocess Vie$ Due to disconnected nature of CTTP re@uest ( res-onse and ability of relational database mana)ement system (!D S), DCCPII tool will handle multi-le users simultaneously$ Therefore, concurrency issues such as synchronous versus asynchronous mechanisms will be not considered in this document$

1ser = Creator, !eader or Administrator Session = CTTP session assi)ned by web server automatically C!1D = Create2!ead21-date2Delete

(. ,odule Deco-position Vie$ odule decom-osition view based on -rinci-les se-aration of concerns and abstraction and su--orts )oals of modifiability and usability$

Software Architecture Document DTCPII tool

arch &'#&

+. Data Vie$ The data view re-resents si)nificant -art of the DCCPII tool$ odulari3ation (normali3ation) is selected as desi)n a--roach of -hysical data model$ Data consistency and @uality are enforced throu)h the series of Primary and Norei)n :ey constrains$ Data access will be -rovided only throu)h the user web interface, however Process Tem-late tables (Tem-lates, Com-onents and Subcom-onents) will be filled manually since we are not -lannin) to create s-ecial front2end interface for that$ ,evertheless, the Data "iew structure will allow easy maintainable because all -rocess com-lexity is hidden in the tem-late tables, therefore creatin) or modifyin) -rocess tem-late will re@uire minimum efforts$

Software Architecture Document DTCPII tool

arch &'#&

Software Architecture Document DTCPII tool

#'

arch &'#&

.. Deploy-ent Vie$ DTCPII tool de-loyment has not been considered yet$ All future im-lementation details will be included in this section$ 1/. 0i1e and *erfor-ance "olumes Simultaneous users +' max (/ S< students) Data stora)e under #' E -er user (includin) u-loaded charts) Performance Bith maximum load all transactions well under standard server scri-t ( database connection timeout = &' seconds$ 11. Issues and concerns 1ser authentication ( inte)ration with PS1Ds systems Charts (ima)e) u-loadin) = is it feasible to save ima)es as binary field into database and what the u-load file si3e limits Do we need to create user interface for Process S-ecification Tem-lates The data structure will allow creatin) only two2level -rocess hierarchy (Process Com-onents and Sub2com-onents)$ Additional level of hierarchy will re@uire chan)in) data structure$

Software Architecture Document DTCPII tool

##

arch &'#&