!

DISTRIBUTED SOFTWARE DEVELOPMENT ENVIRONMENT ARCHITECTURAL DESIGN

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

1. Introduction
This work is about the architectural design of a distributed software development environment. We dealt with a scenario in which a software company has been performing research to decompose large-scale software system requirements into a well-structured set of software components that can be developed in parallel among globally distributed development teams. Our system has the aim to solve problems and difficulties encountered among distributed team members: one of these difficulties is maintaining awareness of the evolution of the software design and implementation, work items and bugs, and teammates' activities. The goal of our system is to use technology to partially fill this knowledge flow gap for a distributed team: we propose to solve this problem by means of a "developer dashboard", an information display that a developer could use to quickly get an idea of the recent changes to the software, work items, coworker activities, and so on. The system is represented as a web application. Ideally the most important information would be available at a glance, whereas the developer could investigate deeper into the details by interacting with the system: it is composed by a main page that displays a summary of software evolution information, grouped by categories, and a dedicated page that allows the user to have a detailed view of work items related to his/her role. Furthermore, the system must help developers do rationale investigations. These have been addressed by a rationale page that displays rationale information related to one or more work items. This document is organized as follows: section 1 is this brief introduction; section 2 is about requirements elicitation. Each requirement is mapped on diagrams, which are described in section 3: in that section, we also provide a brief behavioral or structural description of a diagram and a rationale about its requirement mapping. In section 4, we define an UML profile to describe better our system, in order to represent it in its application domain.

A##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

2. Requirements
In this section, we list all the requirements our system must obey. Each of the following requirements will be mapped in diagrams shown in the next section. After this list, we also provide a glossary to explain keywords meaning in requirements elicitation. This list is organized as follows: FR- suffix for Functional Requirements, NFR- suffix for Non-Functional Requirements and G- suffix for Glossary items; requirements are incrementally enumerated.

FR-1: The system is an information display. FR-1.1: The system shows information about work items. FR-1.2: The system can be used only by registered users. FR-2: The system is implemented as a web application. FR-2.1: The system is based on a LAMP platform. FR-2.2: The system reflects a client-server architectural style. FR-3: The system provides a registration procedure. FR-3.1: The system only allows system accounting managers to add a new user account. FR-3.2: Registration procedure requires: username, password, work team, role, email address. FR-3.3: Registration does not require a confirmation. FR-4: The system provides a deletion procedure. FR-4.1: The system only allows System Accounting Manager to delete a user account. FR-4.2: Deletion procedure must provide an email notification. FR-5: The system provides a modification procedure. FR-5.1: The system only allows System Accounting Manager to modify a user account. FR-6: The system provides an authentication procedure. FR-6.1: Only Registered Users and System Accounting Manager can interact with the system. FR-7: The system provides a download procedure. FR-7.1: The system must allow every Registered User to download work items. FR-8: The system provides an upload procedure. FR-8.1: The system must allow Registered Users to upload work items. FR-8.2: The system must store most recent information about the uploaded work item. FR-8.3: The system must allow users to upload newer versions of a work item. FR-8.4: Upload procedure requires: filename, work item name, brief description, role. FR-8.5: The system updates the changes storyboard at any upload. FR-8.6: The system updates the summary and the detailed view at any upload. FR-9: The system provides a changes storyboard. FR-9.1: The system must allow users to restore any previous version of work items of their role. FR-10: The system provides a web interface. # # B##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

FR-10.1: The web interface is composed by a main page. FR-10.2: The web interface is composed by a dedicated page. FR-10.3: The web interface is composed by a rationale page. FR-10.4: The web interface is composed by an authentication page. FR-10.5: The web interface is composed by a system manager page. FR-11: The system provides a set of information categories. FR-11.1: The system organizes each information categories as a set of roles. FR-12: The system provides a summary of information about a software system. FR-12.1: The summary is placed in the main page. FR-12.2: The summary synthesizes important information about the evolution of a software system. FR-12.3: The summary is organized in categories. FR-13: The system provides a detailed view of information. FR-13.1: The detailed view is conforming to user!s role. FR-13.2: The detailed view is placed in the dedicated page. FR-14: The system provides an activity creation procedure. FR-14.1: The system must allow users to create an activity. FR-14.2: The system creates an activity with a set of mandatory fields (activity name, start date, end date, location, attending users, topic) and a set of optional fields (description, guests, related work items). FR-14.3: The system updates the calendar of activities as an activity has been created. FR-14.4: The system notifies attending users as an activity has been created. FR-15: The system provides an activity modification procedure. FR-15.1: The system must allow attending users to modify an activity. FR-15.2: The system must allow users to modify both mandatory and optional fields. FR-15.3: The system updates the calendar of activities as an activity has been modified. FR-15.4: The system notifies attending users as an activity has been modified. FR-16: The system provides an activity deletion procedure. FR-16.1: The system must allow attending users to delete an activity. FR-16.2: The system updates the calendar of activities as an activity has been deleted. FR-16.3: The system notifies attending users as an activity has been deleted. FR-17: The system provides a calendar of activities. FR-17.1: The calendar of activities is placed in the sidebar gadget. FR-18: The system provides a brief resume of user!s features and activities. FR-18.1: The brief resume is placed in the sidebar gadget. FR-19: The system provides a rationale subsystem. FR-19.1: The rationale subsystem allows users to upload a rationale document with: rationale subject, rationale users involved, rationale content, and related work items. FR-19.2: The system updates automatically the Rational Page at any rationale upload. FR-20: The system provides a backup procedure. FR-20.1: The backup procedure is automatic. FR-20.2: The backup procedure can be also invoked by System Accounting Manager. # # C##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

FR-20.3: The backup procedure allows only the System Accounting Manager to download a ZIP file of system backup.

NFR-1: Privacy NFR-1.1: The system must allow viewing of information to every user, regardless of his role. NFR-1.2: The system must allow users to upload, modify and delete only work items belonging to their own role. NFR-2: Security NFR-2.1: Authentication procedure must be done by means of a secure connection to encode passwords (HTTPS). NFR-3: Usability NFR-3.1: The system provides a user interface that should be intuitive and easy to understand. NFR-4: Performance NFR-4.1: The system must response in a reasonable response time. NFR-4.2: The maximum response time for online-functions should be 10 sec. NFR-4.3: The maximum response time for queries should be 30 sec. NFR-4.4: The system must support 200 simultaneous users. NFR-4.5: The system should support considerable data volumes. NFR-4.6: The system update its own information in real-time. NFR-5: Availability and Fault Tolerance NFR-5.1: The system must be operating and usable 24/7. NFR-5.2: The system must avoid data loss. NFR-5.3: In case of failure, the system should restore data no older than 12 hrs. NFR-6: Integrity NFR-6.1: The system must check that all data has reasonable values. NFR-6.2: The system should not allow empty mandatory fields. NFR-6.3: The system must check that work items are conforming to their own type. NFR-6.4: The system must only accept activities with start date that precedes end date. NFR-6.5: The system must only accept activities with a number of attending people that is equal or greater than two. NFR-7: Localization NFR-7.1: The system is available only in English language. NFR-8: Accessibility NFR-8.1: The system should be accessible from web browsers. NFR-8.2: The system provides offline and online help guide. NFR-9: Extensibility NFR-9.1: The system must be scalable.

G1) Information. The information is composed by the work time and any related description in terms of properties and changes. G2) Work item. A work item is an work outcome about a specified set of things: recent changes, rationale documents, team!s or user!s email and conversation, static and # # D##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

dynamic analysis results, source code, design documents, specifications documents, execution results. Each work item is accessible to a set of users that have a certain role. G3) System accounting manager. The system accounting manager is the responsible for the creation, modification and deletion of users accounts. G4) Changes storyboard. The changes storyboard shows latest changes in work items. This changes are grouped and shown by categories. G5) Summary. The summary is the generic view of the software system to be developed. It is shown grouped by categories. G6) Detailed view. The detailed view is a detailed description of the work items evolution for those work items that belong to the user!s role. G7) Role. A role is a set of user!s tasks. G8) Category. A category is a set of roles. G9) Activity. An activity is an event among two or more people. G10) Attending user. User that attends to an activity. G11) Rational content. The rationale content may be about: design decisions, explanation of implementation changes, conversations among coworkers.

E##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

3. Diagrams
In this section, we describe the system architecture from three different views: static, dynamic and deployment view. In subsection 3.1, we describe the structure of our system, by means of a Component Diagram. In subsection 3.2, we describe the behavior and all the possible use cases of our system by means of Use Case and Sequence Diagrams. In subsection 3.3, we describe the deployment of our system by means of a Deployment Diagram.

3.1 Static View - Component Diagram

F##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

Figure 3.1 Static view of the system (component diagram).

Description This Component Diagram shows the structure of the system (DSDE, thereafter). First of all, we detected the most important components of DSDE: UserManager: this component manages accounting procedures and data providing for both user categories (described later). ActivityManager: this component allows system to create, delete, and modify activities. It also allows the system to show the activities calendar and to notify users about activity changes. WorkItemManager: this component contains procedures that manage work items. It allows to upload, to download, and to list work items. In addition, it allows system to restore a work item previous version. BackupManager: this is the component that is responsible to backup data about users, activities and work items. RationalTracker: this component allows system to track all the rationale items, by creating or listing them. Database: this component represents a database that stores information about users, activities and work items. Authentication: this component allows users to authenticate themselves to the system. SystemManagerPage: this component allows System Accounting Manager to register, modify, and delete Registered Users and to request and export backup. MainPage: this component shows a summary of the evolution of the software at a glance. It!s composed by three subcomponents: o SidebarGadget: this subcomponent shows a brief user resume and the activity calendar. o MPMainSection: this subcomponent shows a summary of new or updated work items, allowing Registered Users to download them. o GenericStoryboard: this subcomponent shows the whole evolution history of the software. DedicatedPage: this component shows a detailed view of work items of a specified role. It!s composed by three subcomponents: o SidebarGadget: this subcomponent shows a brief user resume and the activity calendar. o DPMainSection: this subcomponent shows a detailed view of new or updated work items related to the Registered User!s role. It allows Registered Users to upload work items and, optionally, their related rationale. It also allows Registered Users to download listed work items. o DedicatedStoryboard: this subcomponent shows the evolution history of the work items of Registered User!s role. It allows Registered Users to restore a previous version of a work item. RationalPage: this component allows Registered Users to upload a rationale related to a work item. # # G##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

Requirements Mapping Due to multiplicity of requirements mapped on diagrams, we list them textually, putting together a component and related requirements. Authentication: FR-6, FR-10, FR-10.4. SystemManagerPage: FR-3, FR-3.1, FR-3.2, FR-4, FR-4.1, FR-5, FR-5.1, FR-10, FR-10.5, FR-20.2, FR-20.3. MainPage: FR-10, FR-10.1, FR-12, FR-12.1. DedicatedPage: FR-8, FR-10.2, FR-13, FR-13.1, FR-13.2. MPMainSection: FR-7, FR-7.1, FR-11, FR-11.1, FR-12, FR-12.1. DPMainSection: FR-7.1, FR-8.1, FR-8.2, FR-8.3, FR-8.4, FR-13, FR-13.1, FR-13.2. GenericStoryboard: FR-8.5, FR-9. DetailedStoryboard: FR-8.5, FR-9, FR-9.1 SidebarGadget: FR-14, FR-14.1, FR-14.2, FR-15, FR-15.1, FR-16, FR-16.1, FR-17, FR-17.1, FR-18, FR-18.1. RationalPage: FR-10, FR-10.4, FR-19, FR-19.1. BackupManager: FR-20, FR-20.1. 3.2 Dynamic View Use Case and Sequence Diagrams. In this section we split dynamic view in two points of view: we show the Registered User point of view and the System Accounting Manager point of view. For both points of view, we provide a Use Case Diagram, and for each use case belonging to them we show a Sequence Diagram in order to show how user interacts with the system. 3.2.1 Registered User

Figure 3.2 Registered User Use Case Diagram (Dynamic View)

H##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

In this diagram, we show all possible uses that a Registered User can do with DSDE. We show a Sequence Diagram for each use case in order to describe their functionalities. a) Authentication: a Registered User must authenticate him/herself to the system, in order to do other operations (i.e., upload a work item). In case of authentication success, the system logs the user and notifies him/her; otherwise, the system notify for authentication failure. Note: without loss of information, we precise that this operation is the same both for Registered User and System Accounting Manager.

Figure 3.3 Authentication Sequence Diagram (Dynamic View)

b) Create Activity: a Registered User can create an activity involving other users. The system will automatically update the calendar shown in the SidebarGadget component.

I##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

Figure 3.4 Create Activity Sequence Diagram (Dynamic View)

c) Modify Activity: a Registered User can modify an activity involving other users. The system will notify users about activity modification. The system will automatically update the calendar shown in the SidebarGadget component.

Figure 3.5 Modify Activity Sequence Diagram (Dynamic View)

d) Delete Activity: a Registered User can delete an activity involving other users. The system will notify users about activity deletion. The system will automatically update the calendar shown in the SidebarGadget component.

Figure 3.6 Delete Activity Sequence Diagram (Dynamic View)

AJ##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

e) Upload Work Item: a Registerd User can upload a new work item or a new version of it. A Registered User can optionally provide a rationale document about a work item. The system will automatically update information about the work item and it will automatically update their own component that shows this information (MPMainSection, DPMainSection, GenericStoryboard, DedicatedStoryboard).

Figure 3.7 Upload Work Item Sequence Diagram (Dynamic View)

AA##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

f) Upload Rationale Item: a Register User can upload a Rationale Item about a previous uploaded work item or a set of previous uploaded work items. The system will automatically update information about rationale documents within Rationale Page.

Figure 3.8 Upload Rationale Item Sequence Diagram (Dynamic View)

g) Restore Previous Work Item Version: a Register User can restore a previous version of a work item. The system will automatically update GenericStoryboard and DedicatedStoryboard.

Figure 3.8 Upload Rationale Item Sequence Diagram (Dynamic View)

AB##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

3.2.2 System Accounting Manager

Figure 3.9 System Accounting Manager Use Case Diagram (Dynamic View)

In this diagram, we show all possible uses that a System Accounting Manager can do with the system. We show a Sequence Diagram for each use case in order to describe their functionalities. a) Authentication: see subsection 3.2.2, paragraph a). b) Register User: a System Accounting Manager can create user accounts in order to allow users to use the system.

Figure 3.10 Register User Sequence Diagram (Dynamic View)

AC##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

c) Modify User: a System Accounting Manager can modify user account information. Procedure are similar to Register User, System Accounting Manager calls a different operation (modifyUser, instead of registerUser). d) Delete User: a System Accounting Manager can delete a user account. The system will automatically notify deleted user about deletion.

Figure 3.11 Delete User Sequence Diagram (Dynamic View)

e) Request For Backup: a System Accounting Manager can request for backup. This operation is automatic for the system, but the system itself allows System Account Manager to request for backup in case of necessity.

Figure 3.12 Request For Backup Sequence Diagram (Dynamic View)

AD##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

f) Export Backup: a System Accounting Manager can export a backup on his/her own client as a ZIP file.

Figure 3.13 Export Backup Sequence Diagram (Dynamic View).

Requirements Mapping Without loss of information, we list requirements mapping only for sequence diagram. Relation between sequence diagram requirements mapping and use cases is trivial. Register User: FR-3.3. Modify User: FR-5.1. Delete User: FR-4.2. Authentication: FR-6.1. Request For Backup: FR-20.2. Export Backup: FR-20.3. Create Activity: FR-14.3. Modify Activity: FR-15.2, FR-15.3, FR-15.4. Delete Activity: FR-16.2, FR-16.3. Upload Work Item: FR-8.4, FR-8.5, FR-8.6. Upload Rationale Item: FR-19.2. Restore Previous Work Item Version: FR-9.1.

AE##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

3.2.3 System The system has an automatic procedure of backup that can be invoked only by System Accounting Manager, in order to make a needed backup and/or to save it. The following explains how the automatic procedure works. Description a) Backup: The system automatically backup data about users, activities, work items and rationale items. Backup Manager stores the backup outcome.

Figure 3.14 Backup Sequence Diagram (Dynamic View) Requiments Mapping Backup: FR-20, FR-20.1, NFR-5.3.

AF##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

3.3 Deployment Diagram Deployment View

Figure 3.15 Deployment Diagram (Deployment View) Description In this diagram there!s a description of how our system is deployed. Our system can only be used by web browser on clients such Laptops and Desktop: it doesn!t allow users to use it by mobile devices. DSDE use HTTPS protocol to communicate among nodes, so each communication path has to be intended as a communication by means of HTTPS protocol. DSDE has a client-server architecture style: it can be used by means of clients previously described, and it works on two different kinds of nodes, Application Host and Data Host (later described in UML Profile Section). In this way, we can also guarantee that the system is scalable. Finally, DSDE has a backup node, separated from the other nodes, in order to prevent data loss in case of Application Host and Data Host failure. Requirements Mapping Deployment Diagram: FR-2.1, NFR-2.1, NFR-8.1, NFR-5.2, NFR-9.1.

AG##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

3.4 UML Profile We provide three different diagrams in order to show better the UML profile that we created for our application domain: static view profile, dynamic view profile and deployment view profile. All of them belong to the same module, DSDEProfile. Description a) DSDEStaticElements: this profile has been created in order to specialize Component elements. A Page is a component that has also a filename, an URL and a description. For each Page we have zero or more Section, that has a position and a declared type. In particular a Section is a information container: it can be composed by zero or more subsections (defined as Section themselves). Manager is a component that deals with data. It doesn!t deal with the user directly but provides services in order to be used by graphical user interface. Tracker is a component that keep track of something: in DSDE case, it tracks rationale items.

b) DSDEDynamicElements: In this diagram we extended the concept of Actor, in order to distinguish two different kinds of users that deal with our system. A Register User is a user that only can deal with system functionalities about work items, activities and rationale items. A System Accounting Manager is a user that only can deal with user accounts and system backup.

AH##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

c) DSDEDeploymentElements: We extended the concept of device, in order to identify two different kinds of main elements of a deployment view: Client is the device where user can deal with the system, both for Registered User and System Accounting Manager; Server is the device that contains execution enviroments for application, data storing and retrieving and backup.

3.4.1 Examples of UML Profile stereotypes applications.

DSDEStaticElements stereotypes application (Page and Section).

DSDEDynamicElements sterotypes application (Registered User).

AI##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

DSDEDeploymentElements stereotypes application (Client and Application Host).

BJ##

!"#$%&&'(()*#+"#,-./-0)((-#

1).23)452'6#7%829-3'#1'0'(%:;'<2#=<0)<3%<;'<2#>3/?)2'/253-(#1'.)@<#

DISTRIBUTED SOFTWARE DEVELOPMENT ENVIRONMENT ARCHITECTURAL DESIGN

BA##