Method

We use the GOALS structure (Figure 26) to illustrate how each component is produced in each method steps. Steps 1 to 4 refer to the Analysis phase and Enterprise Structure, and Steps 5 to 8 refer to the Design phase and the Software Architecture. In the GOALS structure it is possible to identify that the Service Design (Step 1) and Business Process Design (Step 2) involve the BP and DE, and, BP and UT, concepts, respectively. This happens in the course of composing the Enterprise Structure (Step 3), complementing it with the IX and BR concepts using the

Enterprise Architecting Technique. Each identified UT is detailed in User Intentions using a

Task Model (Step4) and applying the Software Architecting Technique, as the first level of the application of the CONCUR TASK TREES (CTT) method, structuring the system in terms of available Interaction Components (user tools), which at this stage may be physical or electronic, and the corresponding higher-level UISRs and DBSRs. The Design further specifies each User Intention using an Interaction Model (Step 5), in a second level of the CTT and the Software

Architecting Technique, integrated with the BEHAVIOR DRIVEN DEVELOPMENT (BDD)

method, conceiving the User Interface, and further structuring the system with IOs, UISRs and DBSRs, proceeding towards the finish by structuring the Business Logic (Step 6), the Database (Step 7), and the Software Architecture (Step 8).

Figure 26. GOALS Method Steps (1 to 8) and suggested Techniques.

Together with the Method, the GOALS structure defines the GOALS Enterprise Architecture and the set of structured techniques that allow understanding how the whole business and software structures are elaborated (modeled). The Service Design, the Business Process Design and the Enterprise Structuring (Steps, 1, 2 and 3), apply the Production Logic, specifying the production of the BPs in terms of DEs, the Cooperation Logic, specifying the cooperation between actors in IXs, and the Interaction Space Logic, that specifies the BRs and DEs which are used in each IX. By means of the detail of the UT and the specification of a User Interface (an AS) by means of the Software Architectural Support, and the application of a Task Model (Step 5) and an Interaction Model (Step 6), for a task decomposition according to the essential

use cases and BEHAVIOR DRIVEN DEVELOPMENT (BDD) techniques that identify all the

Business Logic (BRs, UISRs and DBSRs) of the system is identified. Then, all the identified artefacts (GOALS concepts - UML classes) are structured still in a top-down process, based on the common meaning identified along the method and expressed as DEs in a Domain Model. The GOALS method steps are processed according to the ongoing SDP that drives the project team coordination in the modeling of each diagram, using objects (instantiations) of the classes of the GOALS structure, which artefacts elaboration require valences in the domains of Enterprise Engineering, Human-Computer Interaction and Software Engineering. For this reason, GOALS maintains the compatibility of each concept so that it may be recognized by each domain practitioners and cooperate in each Step, in a progressive transfer of responsibility from the EE to the SE domain by means of HCI, focusing enterprise development, design and software implementation productivity. The cooperation starts in the Analysis and continues to the Design where users, HCI and SE specialists, conceive the final Software Architecture. EE is related to the roles of Business Owner, Service Designer and Business Process Manager, HCI to User Interface Designer, and SE to Software Architect and Software Developer.

Table 6 presents the artefacts used and produced by the method in the process of developing the business and software models. The “Business Inputs” provide unstructured information that must be available in any format. The “Enterprise Structure”, “User Behavior Specification” and “Software Architecture” are artefacts that take part as inputs (I), outputs (O) or both (I/O) in the “Output Models” of each Step, and may also be used in the subsequent Steps.

Table 6. GOALS Method Steps, Input and Outputs, and Affinity of Responsibility.

Process Analysis Design Responsibility

Artifacts/Steps 1 2 3 4 5 6 7 8 EE HCI SE Business Inputs Business Organization I I * Business Regulations I * Business Concepts I I I I I I * User Collaboration I I I I * * Enterprise Structure Business Process (BP) O I I I *

User Task (UT) O I I I * *

Interaction Space (IX) O I I I * *

Business Rule (BR) IO IO I * *

Data Entity (DE) O IO IO I * *

Human-Computer Interaction

User Intentions O I * *

User Interactions IO * *

Software Architecture-Specific Components

Aggregation Space O I I I * * Interaction Component O I I I * * Interaction Object O I I * * User Interface SR O O IO I I * Database SR O O IO I I * Output Models Service Model O I *

Business Process Model O I I *

Business IX Organization O * *

Enterprise Structure O I I * * *

Task Model O I * * *

Interaction Model O I I I * *

User Interface Design O *

Business Logic Structure O I *

Database Structure O I *

Software Architecture O *

4.2.1. Architectural Control and Agility

The method is oriented by the strategy of defining an iterative BP-sized Analysis and User Task-sized incremental design process to which is given flexibility in the form of a trade-off between agility and business architecture, while maintaining traceability, targeting enterprise architectural control. Agility is applied to the business architecture (the Enterprise Structure), finding the room to apply user-centered techniques in the Interaction Space (IX). The trade-off is explained by means of the brief analysis of two complementary cases of improvement:

• The ones which involve the Enterprise Structure, including Service, BP and UT rearrangement, with a bigger impact in the Software Architecture, more specifically in the software-specific components derived in the Task and Interaction Models;

• The ones which are circumscribed to the Software Architecture and a single IX or a single UT (without BP reorganization) have a bigger probability of involving a smaller number of components, having a smaller impact in the Software Architecture, as all are subject to the same Business Rules (BR) and Data Entities (DE).

Thus, when the enterprise change implies BP reorganization, the method must follow the Analysis and Design phases (Steps 1 to 8), otherwise it may be started from the Design (Steps 5 to 8) upon User Intentions validation (Step 4). This defines the agile trade-off characteristic of GOALS, in which the time invested in the first 3 (Steps) business models (usually expressed in one A4/A3 diagram per model depending on the BPI), has the revenue of the availability of a business requirements structure (the Enterprise Structure/Business Architecture), that becomes the “back-bone” of the Software Architecture by means of the application of user- centered techniques, in a “top-down” process, using the already related business-and-software hybrid concepts of IX, BR and DE, to apply architectural interaction patterns that fully structure the User Interface, Business Logic and Database of the Information System.

4.2.2. Architectural Interaction Patterns

GOALS derives an architectural Human-Computer Interaction (HCI) pattern in function of the interaction design in two steps (4 and 5), which conceive the two layers of User Interface and Business Logic, for the support of the human User Intentions and Interactions, respectively. The pattern defines that every User Intention will be supported by an Interaction Component (IC) and a single UISR which will be responsible for receiving and sending data to and from the Database, and which will execute other UISRs and DBSRs as a support for User Interaction. The second-level UISRs and DBSRs are derived according to the need to build information structures that the system may present to the user, so he may see and understand, followed by the execution of data validation algorithms, according to the existing BRs and the DE’ structure by means of the invocation of the IXs on the AS is based. Alternatively, BRs may be invoked by any other software-specific component to promote architectural and/or SDP optimization. In concrete terms, this User Interface may be a web page or client-side application that loads and presents all the data in fields, which behavior is implemented by the AS, and which saves the data to the Database upon user command. The pattern is called as “Simple – Interaction Design” because the system immediate feedback is not enforced, and because it defines specific architectural support for each User Interaction. The pattern is presented in Figure 27. Other possible interaction patterns are presented in Appendix B – Interaction Patterns.