Ucm A4 Software Architecture - V2

GroupA4 UCM CASE Tool Drawing Plugin Software Architecture Document Version 1.0

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Revision History Date

Version

Description

Author

21/Oct/09

0.1

First draft preparation and added to GoogleDoc repository

Laleh Roostapour

23/Oct/09

0.2

Non-required sections deleted

Kejia Wu

24/Oct/09

0.4

Purpose and Scopes added (draft)

Iman Keivanloo

25/Oct/09

0.5

Use-Case view (draft) added

Pouyan Hamidi

26/Oct/09

0.6

Domain Model (draft) added

Caoyangxin

27/Oct/09

0.7

Process & Implementation views added

Laleh Roostapour

Todo

Public

GroupA4, 12/3/09

Page 2 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Table of Contents 1.

Introduction

2

1.1 1.2 1.3 1.4 1.5

2 2 2 2 2

Purpose Scope Definitions, Acronyms, and Abbreviations References Overview

2.

Architectural Representation

2

3.

Architectural Goals and Constraints

2

4.

Use-Case View

2

4.1 4.2

2

Public

Use-Case Realizations Domain Model

GroupA4, 12/3/09

Page 3 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

QualitySoftware Architecture Document 1.

Introduction This document represents the high level description of the underlying architecture for the Eclipse UCM Plug-in project. The three plug-ins provide an embedded light-weight eclipse CASE TOOL for drawing, validation and statistical analysis of Use-case Maps. The only dependency between these three plug-ins would be a standard XML structure used for importing and exporting the models. To sum up, this document mostly provides the use cases, logical and physical entities and models according to 4+1 views. These components have been designed and selected to support the given use-case view properly. As a result, this document would be the baseline for the further steps of the project from design to implementation and test.

1.1

Purpose As an architectural document established based on 4+1 views, the most significant decisions regarding the software architecture have been presented here. It is needed to mention that XML and the eclipse plug-in framework are the two predefined standards that this project must adopt them. These plug-ins will provide an embedded UCM CASE TOOL that the developers and designers can use them in a well-defined development environment which is Eclipse. The first plug-in is responsible to provide the drawing environment with a limited number of standard notation with the possibility to support the full notation. The second plug-in is responsible to validate the provided UCM model. And the last one is responsible to do some statistical analysis and provide some graphical charts. The Eclipse environment acts like glue between these plug-ins and the XML files are the only way that they can share the UCM models.

Figure 1, The UCM eclipse plug-ins

Use-case maps provide the high-level structural organization of a system and the related behavior. So they fill the current gaps of UML models and help engineers to provide semi-seamless models. However, there Public

GroupA4, 12/3/09

Page 4 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

is no well known UCM eclipse plug-in while there are a lots of UML plug-ins. So this project is going to fill this gap and provide a new baseline for UCM CASE TOOLs. The intended audiences of this document are the project owner representative, the internal project manager, the designers and developers. Besides, the maintainers will use this document as the most important highlevel guide-line in the future. The internal audience will use this document in order to have a general overview on the project. They also can find the standards and criteria should be hold everywhere throw the project development phases. The project manager can use this document in order to find out the main steps of the project and also main use-cases. 1.2

Scope This Software Architecture Document provides an architectural overview of the UCM eclipse plugins. The 4+1 architectural views are provided here although one of them is negligible the others described in the document thoroughly.

1.3

Definitions, Acronyms, and Abbreviations UCM Use case map XML eXtensible Markup Language Scenario path Wiggly lines between components Component Rectangular boxes representing the runtime components Responsibility Specific points within the model Plug-in a computer program that interacts with a host application

1.4

References • R.J.A. Buhr, R. S. Casselman, Use Case Maps for Object-Oriented Systems, Prentice Hall, 1996. • R.J.A. Buhr , Use Case Maps as Architectural Entities for Complex Systems, August 1998. • D. Amyot, G. Mussbacher, Use Case Maps Tutorial, September, 1999. • T. Bray, J. Paoli, Extensible Markup Language (XML) 1.0 (Fifth Edition), November 2008. • P. Kruchten, Architectural Blueprint – the “4+1” View Mode of Software Architecture, IEEE Software, November 1995.

1.1

Overview Section two summarizes the related architectural views and the models. Architectural goals and constrains are described in the third section. Next sections represent the Use-case, logical, process, Implementation and data view.

2.

Architectural Representation The architecture representation of the UCM plug-in project is described using 4+1 views [Krutchen 95]. It is needed to mention that the deployment view is negligible since there is no complicated physical infrastructure. The models related to these views are represented using UML diagrams. •

Public

Use-Case View: Represents the use-cases of the project and the related actors. It can be used to find out the main users of the system and their desired use cases. In the other words, the description of the architecture and most important scenarios is described here which can be used for development of other views. UML Use-case diagrams are used here as the main graphical representation.

GroupA4, 12/3/09

Page 5 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

•

Logical View: The main functionalities provided for the users represented here using some structural and behavioral UML diagrams like class, sequence diagrams. It would be the basis for understanding the structure and organization of the high-level design of the project.

•

Process View: Dynamic aspects of the software will be represented here. It explains the system processes and their inter-communications. It also describes the run-time and the multi-threading issues. As a result, it should address the concurrency and scalability issues. Component and activity diagram would be the two most useful UML diagrams here.

•

Implementation View: This view represents all sub-systems, components and their dependencies. It also described the layers or the other architectural segments and the designated software components. It can be used by project manager in order to assign the responsibilities. IT is needed to mention that UML Package diagram is the best match for representation of this view.

The mentioned views provide a high-level UML specification of the project using several different diagrams. The dependency between the views is shown in the following figure.

Figure 2, The views and their dependency It is needed to mention that some architectural styles and standards have been adopted which will be described in the following sections. In addition to the styles and patterns the overall architectural views according to the 4+1 framework is shown and described in the following figure and table.

Figure 3, 4+1 Architecture View

4+1 View Use Case View

Table 1, Relevant 4+1 views Relevant to UCM Eclipse Plugins?

Logical View

Public

GroupA4, 12/3/09

Page 6 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Implementation View Deployment View Process View

1.

Architectural Goals and Constraints [This section describes the software requirements and objectives that have some significant impact on the architecture; for example, safety, security, privacy, use of an off-the-shelf product, portability, distribution, and reuse. It also captures the special constraints that may apply: design and implementation strategy, development tools, team structure, schedule, legacy code, and so on.]

2.

Use-Case View [This section lists use cases or scenarios from the use-case model if they represent some significant, central functionality of the final system, or if they have a large architectural coverage—they exercise many architectural elements or if they stress or illustrate a specific, delicate point of the architecture.]

2.1

Use-Case Realizations [This section illustrates how the software actually works by giving a few selected use-case (or scenario) realizations, and explains how the various design model elements contribute to their functionality.]

3.

Logical View [This section describes the architecturally significant parts of the design model, such as its decomposition into subsystems and packages. And for each significant package, its decomposition into classes and class utilities. You should introduce architecturally significant classes and describe their responsibilities, as well as a few very important relationships, operations, and attributes.] Generally, this system is designed as MVC architecture. Event/Listener plays as controller, XML contains application model, and a canvas is implemented to port drawing view. Any changes on the canvas invokes updating the application model. UCM Drawing component involves two aspects of application: (1) UCM CASE Drawing; and (2) Eclipse graphical editing plug-in framework wrapper. Three packages are under development to encapsulate the two aspects: presentation package, application package, and database package. Figure 4 shows the essentials of application package. Interface IActionListener with Eclipse graphical editing framework works as the application controller. A special class Canvas is targeting as the application view. Model consistency and persistency are responsible by class UCMModel. In our design, all terminal drawing elements, such as component, responsibility, and path, inherit from a root: Drawing. That improves the application’s extension capability.

Public

GroupA4, 12/3/09

Page 7 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Figure 4 Elementary components of package ca.concordia.cse.sdm.ucm.drawing.

3.1

Overview [This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers.]

Drawing tool plug-in is comprised of three significant packages: presentation package, application package and database package. Each package contains two significant classes: • • •

Presentation package: Toolbox class, Canvas class Application package: EventProcess class, DataProcess class Database package: XMLFile class, DiagramData class

Hierarchy of Significant packages: Public

GroupA4, 12/3/09

Page 8 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Presentation

Application

Drawing tool plug-in

Database

1.1

Architecturally Significant Design Packages [For each significant package, include a subsection with its name, its brief description, and a diagram with all significant classes and packages contained within the package. For each significant class in the package, include its name, brief description, and, optionally, a description of some of its major responsibilities, operations, and attributes.]

Package name: Presentation Brief description: Provides user interface of drawing tool plug-in, mainly including a toolbox and a blank canvas window. It also receives drawing action from user and forms a diagram on canvas. Diagram:

Presentation

Public

Contains

Contains

Toolbox

Canvas

GroupA4, 12/3/09

Page 9 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Significant class: 1) Name: Toolbox class Description: Supplies various toolbox buttons for clicking and dragging to draw diagram. Main Operation: OnDrag(), OnClick() Main Attribute: ButtonList() 2) Name: Canvas class Description: Supplies canvas window, it also receives action and generates diagram

while user is drawing on canvas and sends corresponding message to application package. Main Operation: CreateWindow(), OnReceiveAction(), DrawElement() Package name: Application Brief description: Transforms diagram consisting of its elements and associations into data structure, and saves it as XML format. Diagram: Application Contains

EventProcess

Contains

DataProcess

Significant class: 1)Name: EventProcess class Description: Be responsible for receiving message from presentation package, and forwarding to corresponding event process methods to handle. The diagram data is stored in main memory. Main Operation: OnReceiveMessage(), ProcessMessage() 2)Name: DataProcess class

Public

GroupA4, 12/3/09

Page 10 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Description: Be responsible for saving diagram data to XML file and reading data

from an existing XML file with predefined rule. Main Operation: SaveFile(), OpenFile()

Package name: Database Brief description: Contains attributes of XML format file, elements of diagram and relationship between elements. Diagram: Database Contains

Contains

XMLFile

DiagramData

Significant class: 1) Name: XMLFile class: Description: Includes XML format file information and parsing method. Main Operation: ParseXMLFile() 2) Name: DiagramData class Description: Includes all elements of diagram and association among elements in main memory. Main Attribute: point, component, label, scenario path, fork. 2.

Process View [This section describes the system's decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). Organize the section by groups of processes that communicate or interact. Describe the main modes of communication between processes, such as message passing, interrupts, and rendezvous.] The drawing application is basically driven by events. User actions trigger a range of events: dragging, dropping, selecting, moving, and so on. Those events will be caught by listeners registered by different consumers. With respect to an event, a specific event handler is provided by some component. In our design, UCMModel is responsible for persisting model, which is represented as XML. Interactions between Canvas and UCMModel is shown in Figure 2; and interactions between Canvas and Pallet is shown in Figure 3.

Public

GroupA4, 12/3/09

Page 11 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Figure 5 Interactions between Canvas and UCMModel.

Public

GroupA4, 12/3/09

Page 12 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

Figure 6 Interactions between Canvas and Pallet.

3.

Deployment View [This section describes one or more physical network (hardware) configurations on which the software is deployed and run. It is a view of the Deployment Model. At a minimum for each configuration it should indicate the physical nodes (computers, CPUs) that execute the software and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping of the processes of the Process View onto the physical nodes.]

Public

GroupA4, 12/3/09

Page 13 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

The UCM application will finally provide two components: Canvas and UCMDrawing. As required, the two components are developed and packaged as Eclipse Plug-in. At present, the application does not support distributed environment, so the final release is regarded as a typical desktop application to be deployed. Eclipse plug-in deployment is suitable for this applcaiton.

4.

Implementation View [This section describes the overall structure of the implementation model, the decomposition of the software into layers and subsystems in the implementation model, and any architecturally significant components.] As mentioned previously, this application is designed in MVC architecture. In implementation, we encapsulate both controller and view into the component UCMCavas, and UCMModel is responsible for maintaining application model.

Public

GroupA4, 12/3/09

Page 14 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

Version: 1.0 Date: 31/Oct/09

4.1

Overview [This subsection names and defines the various layers and their contents, the rules that govern the inclusion to a given layer, and the boundaries between layers. Include a component diagram that shows the relations between layers. ]

4.2

Layers [For each layer, include a subsection with its name, an enumeration of the subsystems located in the layer, and a component diagram.]

5.

Data View (optional) [A description of the persistent data storage perspective of the system. This section is optional if there is little or no persistent data, or the translation between the Design Model and the Data Model is trivial.]

6.

Size and Performance [A description of the major dimensioning characteristics of the software that impact the architecture, as well as the target performance constraints.] The final plug-in needs Eclipse 3.0 or later version, and so an environment that can support Eclipse smoothly is necessary. The second constraint is JVM version, which should be 1.6 or later.

Public

GroupA4, 12/3/09

Page 15 of 16

UCM CASE Tool Drawing Plugin Software Architecture Document UCM A4 Software Architecture.doc

7.

Version: 1.0 Date: 31/Oct/09

Quality [A description of how the software architecture contributes to all capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics have special significance, such as safety, security or privacy implications, they must be clearly delineated.] Quality concerns lie in three parts: 1.

1.

UCM elements drawing functionality works sound, including: ◦

Pallet appearance;

◦

Drag-and-drop of drawing components;

◦

Path, fork (and/or), and join (and/or) connection;

◦

Adding/removing connection nodes of fork and join;

◦

Labeling components.

Synchronization between canvas editing and UCM model works sound: ◦

1.

Communication to another two modules should work smooth: ◦

1.

Public

Changing in drawing client (i.e. canvas), adding, editing, removing, connecting, and reconnecting, should trigger updating UCM model; Importing/exporting/saving model must seamlessly support another two modules' operation.

Plug-in can be configured correctly.

GroupA4, 12/3/09

Page 16 of 16