Web Content Management System, Migration and Maintenance Services for ECDC Web Portal

(1)

Web Content Management System, Migration and Maintenance Services for ECDC Web Portal - Reference H

Page | 1

Web Content Management System, Migration and

Maintenance Services for ECDC Web Portal

Current System Description – Reference H

March 2015

(2)

Page | 2

1. Introduction ... 4

1.1. Purpose and Scope ... 4

1.2. How the SAD Is Organized ... 5

2. Architecture Background ... 22

2.1. Problem Background ... 22

System Overview ... 22

2.1.1. Goals and Context ... 23

2.1.2. Significant Driving Requirements ... 23

2.1.3. 2.2. Solution Background ... 24 Architectural Approaches ... 24 2.2.1. Analysis Results... 25 2.2.2. Requirements Coverage ... 25 2.2.3. Summary of Background Changes Reflected in Current Version ... 28

2.2.4.

3. Views ... 28

3.1. Logical View ... 29

View Description ... 29

3.1.1. View Packet Overview ... 29

3.1.2. Architecture Background ... 30

3.1.3. View Packet: Entity relations diagram ... 30

3.1.4. View Packet: Sequence diagram... 30

3.1.5. 3.2. Development / Implementation View ... 31

3.2.3. View Packet: Component diagram ... 34

3.2.4. View Packet: Package diagram ... 34

3.2.5. 3.3. Process View ... 37

3.3.3. View Packet: Activity diagram ... 38

3.3.4. 3.4. Physical / Deployment View ... 38

3.4.2. 3.5. Scenarios / Use-cases View ... 39

3.5.3. View Packet: Use-case diagram ... 39

3.5.4.

4. Relations Among Views ... 54

5. Referenced Materials ... 55

6. Appendices... 56

(3)

Page | 3

List of Figures

FIGURE 1: WEB PORTAL 1.1. ... 23

FIGURE 2: ECDC VISUAL IDENTITY ... 26

FIGURE 3: LEFT HAND NAVIGATION ... 27

FIGURE 4: SOCIAL NETWORK LINKS ... 28

FIGURE 5: SEQUENCE DIAGRAM FOR THE CREATION AND PUBLICATION OF A NEW PAGE TO THE WEB PORTAL . 31 FIGURE 6: COMPONENT DIAGRAM ... 34

FIGURE 7: ADVISORY FORUM CRM DATA ACCESS ... 35

FIGURE 8: CRM COMPETENT BODIES DATA ACCESS ... 35

FIGURE 9: MANAGEMENT BOARD CRM DATA ACCESS ... 36

FIGURE 10: CONTENT TYPE HUB ... 37

FIGURE 11: ACTIVITY DIAGRAM FOR THE PAGE APPROVAL ... 38

FIGURE 12: ADVISORY AND MANAGEMENT WEB PART USE CASE DIAGRAM ... 40

FIGURE 13: ECDC WEB CONTENT BOX WEB PART USE CASE DIAGRAM ... 41

FIGURE 14: COUNTRY INFORMATION SMALL MAP WEB PART USE CASE DIAGRAM ... 42

FIGURE 15: CUSTOM FORM USE CASE DIAGRAM ... 43

FIGURE 16: ECDC CONTENT QUERY WEB PART USE CASE DIAGRAM ... 44

FIGURE 17:ECDC TV WEB PART USE CASE DIAGRAM ... 45

FIGURE 18: EVENTS WEB PART USE CASE DIAGRAM ... 46

FIGURE 19: RELATED PAGES WEB PART USE CASE DIAGRAM ... 47

FIGURE 20:FILTER PICTURE LIBRARY WEB PART USE CASE DIAGRAM ... 48

FIGURE 21: HEALTH TOPICS WEB PART USE CASE DIAGRAM ... 49

FIGURE 22: IMAGE ROTATOR WEB PART USE CASE DIAGRAM ... 50

FIGURE 23: RELATED NEWS WEB PART USE CASE DIAGRAM ... 51

FIGURE 24: OPEN DOCUMENT WEB PART USE CASE DIAGRAM ... 52

FIGURE 25: PICTURE VIEWER WITH DROPDOWN WEB PART USE CASE DIAGRAM ... 53

(4)

Page | 4

1. Introduction

Sub-sections of Section 1 include the following.

 Section 1.1 (“Purpose and Scope”) explains the purpose and scope of the SAD, and indicates what information is and is not included. This tells you if the information you’re seeking is likely to be in this document.

 Section 1.2 (“How the SAD Is Organized”) explains the information that is found in each section of the SAD. This tells you what section(s) in this SAD are most likely to contain the information you seek.

1.1. Purpose and Scope

This SAD specifies the software architecture for the Web Portal of ECDC. The Web Portal is built on Microsoft SharePoint platform. Since SharePoint applications heavily depend on the underlying SharePoint farm and its configuration, corresponding information will also be included where it is relevant. All information regarding the software architecture may be found in this document, although much information is incorporated by reference to other documents.

What is software architecture? The software architecture for a system*_{is the structure or structures of}

that system, which comprise software elements, the externally-visible properties of those elements, and the relationships among them [Bass 2003]. "Externally visible” properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. This definition provides the basic litmus test for what information is included in this SAD, and what information is relegated to downstream documentation.

Elements and relationships. The software architecture first and foremost embodies information about how the elements relate to each other. This means that architecture specifically omits certain

information about elements that does not pertain to their interaction. Thus, a software architecture is an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. Elements interact with each other by means of interfaces that partition details about an element into public and private parts. Software architecture is concerned with the public side of this division, and that will be documented in this SAD accordingly. On the other hand, private details of elements—details having to do solely with internal implementation—are not architectural and will not be documented in a SAD.

Multiple structures. The definition of software architecture makes it clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. The neurologist, the orthopedist, the hematologist, and the dermatologist all take a different perspective on the structure of a human body. Ophthalmologists, cardiologists, and podiatrists

concentrate on subsystems. And the kinesiologist and psychiatrist are concerned with different aspects of the entire arrangement’s behavior. Although these perspectives are pictured differently and have very different properties, all are inherently related; together they describe the architecture of the human body. So it is with software. Modern systems are more than complex enough to make it difficult to grasp them all at once. Instead, we restrict our attention at any one moment to one (or a small number) of the software system’s structures. To communicate meaningfully about an architecture, we must make clear which structure or structures we are discussing at the moment—which view we are taking of the

(5)

Page | 5 architecture. Thus, this SAD follows the principle that documenting a software architecture is a matter of documenting the relevant views and then documenting information that applies to more than one view.

None of these structures alone is the architecture, although they all convey architectural information. The architecture consists of these structures as well as many others. This example shows that since architecture can comprise more than one kind of structure, there is more than one kind of element (e.g., implementation unit and processes), more than one kind of interaction among elements (e.g.,

subdivision and synchronization), and even more than one context (e.g., development time versus runtime). By intention, the definition does not specify what the architectural elements and relationships are. Is a software element an object? A process? A library? A database? A commercial product? It can be any of these things and more.

These structures will be represented in the views of the software architecture that are provided in Section 3.

Behavior. Although software architecture tends to focus on structural information, behavior of each element is part of the software architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the software architecture and will be documented in the SAD as such. Behavior is documented in the element catalog of each view.

1.2. How the SAD Is Organized

This SAD is organized into the following sections:

 Section 1 (“Introduction”) provides information about this document and its intended audience. It provides the roadmap and document overview. Every reader who wishes to find information relevant to the software architecture described in this document should begin by reading Section 1, which describes how the document is organized, which stakeholder viewpoints are represented, how stakeholders are expected to use it, and where information may be found. Section 1 also provides information about the views that are used by this SAD to communicate the software architecture.

 Section 2 (“Error! Not a valid bookmark self-reference.”) explains why the architecture is what it is. It provides a system overview, establishing the context and goals for the development. It describes the background and rationale for the software architecture. It explains the constraints and influences that led to the current architecture, and it describes the major architectural

approaches that have been utilized in the architecture. It includes information about evaluation or validation performed on the architecture to provide assurance it meets its goals.

 Section 3 (Views”) and Section 0 (“The utilization of the web parts is one of the most important and used in Web Portal. Below are the use cases for a selection of web parts:

(6)

Page | 6

(7)

Page | 7

(8)

Page | 8

(9)

Page | 9

(10)

Page | 10

(11)

Page | 11

(12)

Page | 12

(13)

Page | 13

(14)

Page | 14

(15)

Page | 15

(16)

Page | 16

(17)

Page | 17

(18)

Page | 18

(19)

Page | 19

(20)

Page | 20

Figure 26: Photo Gallery Small picture web part use case diagram

 Relations Among Views”) specify the software architecture. Views specify elements of software and the relationships between them. A view corresponds to a viewpoint, and is a representation of one or more structures present in the software (see Section 1.1).

(21)

Page | 21  Referenced Materials”) and Appendix (“Appendix: Glossary and Acronym List”) provide

reference information for the reader. Section 5 provides look-up information for documents that are cited elsewhere in this SAD. Section 6.1 is a directory, which is an index of architectural elements and relations telling where each one is defined and used in this SAD. The section also includes a glossary and acronym list.

(22)

Web Content Management System, Migration and Maintenance Services for ECDC Web Portal - Reference H Page | 22

2. Architecture Background

2.1. Problem Background

System Overview

2.1.1.

The Web portal is the public ECDC web site used to emit information regarding ECDC work and programmes. The current version 1.1 was out on the 13th_{of September of 2013 and is powered by} SharePoint 2010. The Web Portal 1.0 was powered by SharePoint 2007 and went live at September 2009.

(23)

Page | 23

Figure 1: Web Portal 1.1.

Goals and Context

2.1.2.

The general goal/objective of the Web Portal it to provide an overview of the mission and activities of ECDC. More specifically it offers detailed information about the organization, its activities, various health topics, list of its publications and related media.

Significant Driving Requirements

2.1.3.

(24)

Page | 24 1. Compliance with ECDC branding. All ECDC related material has some specific color and style

guidelines;

2. Left hand navigation in all content pages

(http://ecdcintranet.ecdcnet.europa.eu/OrgAndMe/workspaces/wss/WebPortalspace/1.1/Specific ations/BasicNavigation_Portal1.1_v1.0.xlsx);

3. Improved usability

4. Timely notification of users: Social bookmarking.

5. Content editors should be able to modify content and add functionality to pages

2.2. Solution Background

Architectural Approaches

2.2.1.

ECDC as an organization is using Microsoft technologies, making this a natural choice also for the Web Portal. More specifically Microsoft SharePoint is the application platform that Web Portal is built on. In light of this the system is based on / using:

 (Development platform) The .NET framework v3.5 and the C# programming language;  (Development environment) Visual Studio 2010 Team System;

 (Database software) MS SQL Server technologies utilized by SharePoint Farm;  (Web server) Internet Information Services (IIS);

 (Server operating system) Windows Server technologies;  (Email server) Microsoft Exchange;

 (Deployment): SharePoint solution packages and Windows PowerShell scripts

MS SharePoint version 2010 is the version that currently powers the big majority of content 1.1 version of the Web Portal except the following sub sites: EPIET, ESCAIDE, EAAD migration. Various features of SharePoint are utilized inside the web portal. More specifically:

Managed metadata service: This is a SharePoint feature that facilitates the publishing and subscription of managed terms or words in order to govern companywide taxonomy.

Content types: A content type is a group of reusable settings that describe the shared attributes and behaviors for a specific kind of content. Content types can be defined for any item type, including documents, list items, media files, and folders.

Document libraries: They are used for storing various types of files like Word documents, Excel spreadsheets, text files, Pdf documents.

Timer Jobs: They are periodically executed tasks inside SharePoint Server. They provide a task execution environment.

CSS Styles: Web Portal common branding comes in the form of CSS stylesheets. SharePoint supports the custom branding of the different websites.

(25)

Page | 25

Javascript: Custom javascript is utilized by SharePoint in order to enhance the client side experience of the user.

Masterpages and layouts: Different master pages form the basic structure of the various pages of the portal (admin, search, public pages) while page layouts arrange the structure of different pages inside different sections (health topics, home, web part page etc)

Resource files: They are used for making the application content easily available to multiple languages

RSS feeds: Really Simple Syndication (RSS) is a widely used technology for transmitting information across the Internet and intranets. SharePoint offers support for syndicating content from the various lists.

Business Data Catalog: A SharePoint feature for integrate business data from back-end server applications. The web portal can present data from CRM by the aid of this.

Web Parts: This is a component on a web page, some code/functionality packaged in the form of Web Part. They are reusable. In addition to the out of the box web parts, custom ones are utilized by the portal

Content Type Hub: it allows the centralization and sharing of content types through the Metadata Service Application.

Content deployment: it deploys content from a source site collection to a destination site collection. The complete source site collection can be deployed, or a subset of sites can be deployed.

In addition to special SharePoint features, the web portal utilizes some special ASP.NET features:

Http handlers: An ASP.NET HTTP handler is the process (frequently referred to as the "endpoint") that runs in response to a request made to an ASP.NET Web application (like SharePoint). The web portal is utilizing handlers to redirect old urls (before the migration) to new urls and for serving RSS feeds,

Analysis Results

2.2.2.

The architecture is based on the principles exposed in the book “Patterns of Enterprise Application Architecture” (Martin Fowler, 2002), which is considered as a reference in the field of enterprise application development.

No formal analysis has been performed to evaluate the architecture.

Requirements Coverage

2.2.3.

(26)

Page | 26 1. It adopts the ECDC design guidelines with a strong ECDC identity;

(27)

Page | 27 2. Left hand navigation in all content pages;

Figure 3: Left hand navigation

3. In order to improve usability larger font size is used, less words per line are placed, and bullets are used to make lists clearer

(28)

Page | 28 4. Timely notification of users: Social bookmarking.

Figure 4: Social network links

5. Content editors can add, configure or remove web parts on various pages in order to add functionality.

Summary of Background Changes Reflected in Current Version

2.2.4.

3. Views

The views presented in this SAD are the following:

Name of view Rationale Module view? Component- and-connector view? Allocation view?

Logical Describes how the system is structured in

terms of units of implementation. The elements are packages, classes, and interfaces. The relationship between

(29)

Page | 29 elements shows dependencies, interface

realizations, part-whole relationships, and so forth.

Example diagrams: Entity Relations Diagram, Class Diagram, Sequence Diagram

Development / Implementation

Describes how development artifacts are organized in the file system. The elements are files and directories (any configuration items). This includes development artifacts and deployment artifacts.

Example diagrams: Component Diagram, Package Diagram

Yes

Process Describes how the run-time system is

structured as a set of elements that have run-time behavior and interactions. Example diagram: Activity Diagram

Yes

Physical / Deployment

Describe how the system is mapped to the hardware.

Example diagram: Deployment Diagram

Yes Yes

Scenarios / Use-cases

Describes functionality of the system, its external interfaces, and its principal users. Example diagram: Use Case Diagrams

3.1. Logical View

View Description

3.1.1.

The logical architecture primarily supports the functional requirements—what the system should provide in terms of services to its users. The system is decomposed into a set of key abstractions, taken (mostly) from the problem domain, in the form of objects or object classes. They exploit the principles of abstraction, encapsulation, and inheritance. This decomposition is not only for the sake of functional analysis, but also serves to identify common mechanisms and design elements across the various parts of the system.

View Packet Overview

(30)

Page | 30 This view has been divided into the following view packets for convenience of presentation:

 Entity relations diagram: Shows the entities at play and their internal relationship between each other.

 Class diagram: Describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.

 Sequence diagram: Shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.

Architecture Background

3.1.3.

The Web portal 1.1 is developed in SharePoint 2010. This was a natural choice since the previous Web Portal was running on SharePoint 2007 and the migration would be easier. SharePoint is quite suitable for the creation of web sites or intranets. It offers comprehensive security model, with definition of different roles. Additionally the content editing and the web part usage empower the content editors to add by themselves information and functionality to the pages.

View Packet: Entity relations diagram

3.1.4.

Not applicable.

View Packet: Sequence diagram

3.1.5.

Web editor team members do not access directly the production Web Portal environment. Instead, they are making any updates to the staging environment. As soon as they select to publish a page, SharePoint environment takes over: the Content Deployment feature is utilized for transferring the updated content to the production environment. Below is the sequence diagram that describes the procedure:

(31)

Page | 31

Portal environment.

Figure 5: Sequence diagram for the creation and publication of a new page to the web portal

3.2. Development / Implementation View

View Description

3.2.1.

The development architecture focuses on the actual software module organization on the software development environment. The software is packaged in small chunks—program libraries, or subsystems— that can be developed by one or a small number of developers. The subsystems are organized in a hierarchy of layers, each layer providing a narrow and well-defined interface to the layers above it. The development architecture of the system is represented by module and subsystem diagrams, showing the ‘export’ and ‘import’ relationships. The complete development architecture can only be described when all the elements of the software have been identified. It is, however, possible to list the rules that govern the development architecture: partitioning, grouping, visibility. For the most part, the development architecture takes into account internal requirements related to the ease of development, software management, reuse or commonality, and to the constraints imposed by the toolset, or the programming language. The development view serves as the basis for requirement allocation, for allocation of work to teams (or even for team organization), for cost evaluation and planning, for monitoring the progress of the project, for reasoning about software reuse, portability and security. It is the basis for establishing a line-of-product.

View Packet Overview

3.2.2.

This view has been divided into the following view packets for convenience of presentation:

 Component diagram: Describes how a software system is split up into components and shows the dependencies among these components.

(32)

Page | 32  Package diagram: Describes how a system is split up into logical groupings by showing the

dependencies among these groupings.

Architecture Background

3.2.3.

The source code of the application is developed and stored in the form of MS Visual Studio 2010 solution. It consists of multiple sub solutions that are organized in the following subfolders: 3.2.3.1. Applications

It contains the solution for the custom version of RSS feed. 3.2.3.2. BDC

It contains the Business Data Catalog implementations for present data from CRM as SharePoint lists. 3.2.3.3. HttpHandlers

It contains the http handlers that were developed for

- redirecting the SharePoint RSS feeds to the custom implementation of Web Portal RSS feeds,

- redirecting from some old links to the new location of them after the migration. There is a specific list that contains the old and news Url mapping

3.2.3.4. Metadata

Contains the definition for the content types stored in the content type hub. 3.2.3.5. Templates

Contains custom forms used for News, Events, Publications, Scientific Advice, Publications, Call for Grants, Call for Tenders.

3.2.3.6. Tools

Contains various small console applications and tools, used to aid the migration, address issues and bugs, or perform other supporting development tasks.

3.2.3.7. UserInterface

Contains all the artifacts that support the user interface of the portal. More specifically it contains javascript files, master pages, page layouts, stylesheets, form layouts, and an event receiver that performs UI configuration.

3.2.3.8. WebConfig

Contains features that add entries in the web.config. 3.2.3.9. WebParts

This is a quite important subfolder since it contains the work done for the various web parts. More specifically it contains:

(33)

Page | 33 - ECDC.WP.SP.WP.AFMB: used for diplaying the Advisory and Management board members - ECDC.WP.SP.WP.CompetentBody: used at the Competent body page

- ECDC.WP.SP.WP.ContentDisplay: This is a custom content box

- ECDC.WP.SP.WP.CustomForm: It enables the building of custom form by using xml definitions.

- ECDC.WP.SP.WP.FilterPictLibrary: A custom image display control that uses a dropdown list

- ECDC.WP.SP.WP.ImageRotator: used for displaying images from a custom list

- ECDC.WP.SP.WP.Members: used for displaying information from a list containing ECDC contacts.

- ECDC.WP.SP.WP.OpenDocument: Presents the documents of a list as entries inside a dropdown control.

- ECDC.WP.SP.WP.Organization: Displays information from a list containing organizational information items.

- ECDC.WP.SP.WP.PhotoViewerDropDownList: It is a photo viewer web part

- ECDC.WP.SP.WP.TessyRedirection: used for redirecting requests for old urls to the new ones for the TESSy related pages.

- ECDC.WP.SP.WP.TessyReports: Used for displaying TESSy reports as they are retrieved from Reporting Server

(34)

Page | 34

View Packet: Component diagram

3.2.4.

Figure 6: Component diagram

Above the high level component diagram of the application can be found. The Content Type Hub, Managed Metadata Service, CRM and Tessy contribute data that is displayed by the various pages of the Web Portal.

View Packet: Package diagram

3.2.5.

3.2.5.1. CRM integration

CRM provides information to the Web Portal in order to populate three lists: - Advisory Forum

- Management Board

(35)

Page | 35

Figure 7: Advisory Forum CRM data access

(36)

Page | 36

Figure 9: Management Board CRM data access

This is done by using Business Connectivity Services of SharePoint. The related CRM fields for the contacts are mapped to columns of SharePoint lists in order to encapsulate the external CRM data to a SharePoint list form.

(37)

Page | 37 The Content Type Hub is a central location where content types can be defined and published. In this manner there is a central repository of reusable content types. Even updates are reflected to the subscribed web applications.

Such content type hub is utilized by the web portal. Some base content types are defined at the hub. These type are imported in Portal. The imported ones are used again in order to produce new derived custom content types that are specifically tailored to the Web Portal needs.

The following diagram depicts the base types that are provided by the ECDC content type hub.

Figure 10: Content Type Hub

3.3. Process View

View Description

3.3.1.

The process architecture takes into account some non-functional requirements, such as performance and availability. It addresses issues of concurrency and distribution, of system’s integrity, of fault-tolerance, and how the main abstractions from the logical view fit within the process architecture—on which thread of control is an operation for an object actually executed.

A process is a grouping of tasks that form an executable unit. Processes represent the level at which the process architecture can be tactically controlled (i.e., started, recovered, reconfigured, and shut down). In addition, processes can be replicated for increased distribution of the processing load, or for

improved availability. The software is partitioned into a set of independent tasks. A task is a separate thread of control that can be scheduled individually on one processing node.

View Packet Overview

3.3.2.

(38)

Page | 38  Activity Diagram: Describes the business and operational step-by-step workflows of

components in a system. An activity diagram shows the overall flow of control.

Architecture Background

3.3.3. View Packet: Activity diagram

3.3.4.

In specific pages an approval workflow is attached. An example is the “World Health Day 2014” page:

Figure 11: Activity diagram for the page approval

3.4. Physical / Deployment View

View Description

3.4.1.

The physical architecture takes into account primarily the non-functional requirements of the system such as availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes on a network of computers, or processing nodes (or just nodes for short). The various elements identified—networks, processes, tasks, and objects—need to be mapped onto the various nodes. We expect that several different physical configurations will be used: some for development and testing, others for the deployment of the system for various sites or for different customers. The mapping of the software to the nodes therefore needs to be highly flexible and have a minimal impact on the source code itself.

View Packet Overview

3.4.2.

(39)

Page | 39  Deployment diagram: Describes the hardware used in system implementations and the

execution environments and artifacts deployed on the hardware.

3.5. Scenarios / Use-cases View

View Description

3.5.1.

The elements in the four views are shown to work together seamlessly by the use of a small set of important scenarios —instances of more general use cases—for which we describe the corresponding scripts (sequences of interactions between objects, and between processes). The scenarios are in some sense an abstraction of the most important requirements. This view is redundant with the other ones (hence the “+1”), but it serves two main purposes:

 as a driver to discover the architectural elements during the architecture design as we will describe later

 as a validation and illustration role after this architecture design is complete, both on paper and as the starting point for the tests of an architectural prototype.

View Packet Overview

3.5.2.

This view has been divided into the following view packets for convenience of presentation:

 Use-case diagram: Describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.

Architecture Background

3.5.3.

Web portal audience is divided into three categories:

- Public anonymous end users. These are the end users that consume the information presented by the various pages of the web portal. They do not authenticate but access it in an anonymously. - Web Editor Team members. These are the ECDC users that add content to pages, add and

configure web parts, upload images and files.

View Packet: Use-case diagram

3.5.4.

The utilization of the web parts is one of the most important and used in Web Portal. Below are the use cases for a selection of web parts:

(40)

Page | 40

(41)

Page | 41

(42)

Page | 42

(43)

Page | 43

(44)

Page | 44

(45)

Page | 45

(46)

Page | 46

(47)

Page | 47

(48)

Page | 48

(49)

Page | 49

(50)

Page | 50

(51)

Page | 51

(52)

Page | 52

(53)

Page | 53

(54)

Page | 54

Figure 26: Photo Gallery Small picture web part use case diagram

4. Relations Among Views

This document and the views included are based on the 4+1 view model: In November 1995, while working as Lead software architect at Hughes Aircraft Of Canada Philippe Kruchten published a paper entitled: "Architectural Blueprints—The “4+1” View Model of Software Architecture". The intent was to come up with a mechanism to separate the different aspects of a software system into different views of the system. Why? Because different stakeholders always have different interest in a software system. Some aspects of a system are relevant to the Developers; others are relevant to System administrators. The Developers want to know about things like classes; System administrators want to know about deployment, hardware and network configurations and don't care about classes. Similar points can be made for Testers, Project Managers and Customers. Kruchten thought it made sense to decompose architecture into distinct views so stakeholders could get what they wanted. In total there were 5 views in his approach but he decided to call it 4 + 1. [Kruchten 1995]

(55)

Page | 55

5. Referenced Materials

Bass 2003

Bass, Clements, Kazman,

Software Architecture in Practice,

second edition, Addison Wesley Longman, 2003.

Clements 2001

Clements, Kazman, Klein,

Evaluating Software

Architectures: Methods and Case Studies,

Addison Wesley

Longman, 2001.

Clements 2002

Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord,

Stafford,

Documenting Software Architectures: Views and

Beyond

, Addison Wesley Longman, 2002.

IEEE 1471

ANSI/IEEE-1471-2000,

IEEE Recommended Practice for

Architectural Description of Software-Intensive Systems

, 21

September 2000.

Kruchten 1995

Philippe Kruchten,

Architectural Blueprints—The “4+1”

View Model of Software Architecture

, IEEE Software 12

(6), 1995

Olivia Carstocea

15 May 2013

Web Portal 1.1 – Guidelines (v 4.1)

Olivia Carstocea

(from 2010 to

2013)

(56)

Page | 56

6. Appendices

6.1. Appendix: Glossary and Acronym List

Term Definition

software architecture The structure or structures of that system, which comprise software elements, the externally visible properties of those elements, and the relationships among them [Bass 2003]. "Externally visible” properties refer to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on.

view A representation of a whole system from the perspective of a related set

of concerns [IEEE 1471]. A representation of a particular type of software architectural elements that occur in a system, their properties, and the relations among them. A view conforms to a defining

viewpoint.

view packet The smallest package of architectural documentation that could usefully be given to a stakeholder. The documentation of a view is composed of one or more view packets.

viewpoint A specification of the conventions for constructing and using a view; a pattern or template from which to develop individual views by

establishing the purposes and audience for a view, and the techniques for its creation and analysis [IEEE 1471]. Identifies the set of concerns to be addressed, and identifies the modeling techniques, evaluation techniques, consistency checking techniques, etc., used by any conforming view.

Acronym Definition

API Application Programming Interface; Application Program Interface; Application Programmer Interface

ATAM Architecture Tradeoff Analysis Method CMM Capability Maturity Model

CMMI Capability Maturity Model Integration CORBA Common object request broker architecture COTS Commercial-Off-The-Shelf

EPIC Evolutionary Process for Integrating COTS-Based Systems IEEE Institute of Electrical and Electronics Engineers

KPA Key Process Area OO Object Oriented ORB Object Request Broker OS Operating System

(57)

Page | 57

RUP Rational Unified Process

SAD Software Architecture Document SDE Software Development Environment SEE Software Engineering Environment SEI Software Engineering Institute

Systems Engineering & Integration Software End Item

SEPG Software Engineering Process Group SLOC Source Lines of Code

SW-CMM Capability Maturity Model for Software

CMMI-SW Capability Maturity Model Integrated - includes Software Engineering UML Unified Modeling Language

Web Content Management System, Migration and Maintenance Services for ECDC Web Portal