4. FABRICACIÓN Y COSTES DEL DISPOSITIVO
4.5 Modelos físicos de los componentes del sistema
4.5.1 Conectores externos
In order to develop the GOALS language structure, two architectures have been defined to represent the enterprise: the business and software architectures, the Enterprise Structure and the Software Architecture, respectively. Together, they compose the Enterprise Architecture, which is complemented with a process, a method and a set of techniques, which represent the guidelines and way-of-building of business and software models. The Enterprise Architecture concepts provide the notation by means of UML class stereotypes (the symbol), and the relation between the classes is expressed by dependency (usage), meaning that one component depends on the good functioning of the other in order to properly work.
The Enterprise Structure describes the business, which briefly states that: a Business Process (BP) is composed of User Tasks (UT), which are performed by users (or actors) in Interaction Spaces (IX) (whether physical or electronic), applying the enterprise’ Business Rules (BR) over defined Data Entities (DE, which are business concepts). The concepts, definition, origin and symbols of the Enterprise Structure are presented in Table 3.
Table 3. Enterprise Structure Concepts Definition, Origin and Symbol.
Concept Definition Origin Symbol
Business Process
(BP) A Network of UTs that Lead to a Goal GOALS User Task
(UT) A Complete User Task within a BP AM Interaction Space
(IX) The Space that provides UT Support WISDOM Business Rule
(BR)
A Business Restriction over
DE’s Structural Relations DEMO
Data Entity (DE)
Persistent Information
about a Business Concept WISDOM
The Enterprise Structure allows the modeling of the business human activity, of the available
resources (physical or logical) and the existing goals. Maintaining the same top-down logic,
the modeling towards the Software Architecture is carried out by means of the User Interface which supports each UT. The “bridge” between the Enterprise Structure human activity and the Software Architecture is achieved by means of Human-Computer Interaction (HCI) techniques, establishing a relation of UTs, User Intentions and User Interactions with the User Interface’ Aggregation Spaces, Interaction Components and Interaction Objects, respectively. The relation maximizes the modeling of human activity in terms of meaning, and minimizes it in terms of number, inducing the simplification of the system back from the business design.
The interaction concepts which complement the UT in terms of human behavior structuring, are presented in Table 4.
Table 4. Interaction Design Concepts Definition, Origin and Symbol.
Concept Definition Origin Symbol
User Intention The Sequence of Actions that the User
Wishes to Perform to Complete a UT AM
User Interaction The Interaction Inputs of the Information
System Performed by the User GOALS
The Software Architecture defines that an: Aggregation Space (AS) is composed of Interaction Components (IC) that trigger User Interface System Responsibilities (UISR) and Database System Responsibilities (DBSR, both belong the Business Logic layer) by means of the Interaction Objects (IO) and remaining User Interface structure (AS and IC) where HCI occurs (UT, User Intention, and User Interaction), in order to manage existing Enterprise Structure
data (Data Entities, DE), according to the enterprise regulations (Business Rules, BR), as
ensured by the Interaction Space (IX).
The AS, IC, IO, UISR and DBSR are the five software-specific concepts of the Software Architecture, which are architecturally related to the Enterprise Structure by means of the specific relation of one-to-one between the (software) AS and the (business) UT, and of the UT with its supportive IX, inheriting its BRs as parts of the Business Logic, and the DEs as part of the Database. The software-specific concepts, definition, origin and symbol of the Software Architecture are presented in Table 5.
Table 5. Software Architecture Specific Components, Definition, Origin and Symbol.
Concept Definition Origin Symbol
Aggregation
Space A User Interface HYDRA
Interaction
Component Tool of a User Interface
WISDOM HYDRA Interaction
Object A User Interface Object that triggers SRs
HYDRA GOALS User Interface
SR
A SR that provides support for User Interface
data presentation AM/GOALS
Database
SR A SR that manages data AM/GOALS
The concepts and their symbol provide the notation of the language, and the structure that relates both business and software concepts provides the syntax. The semantics of each concept is provided by a semiotic logic (the Ideology) that is applied to the Enterprise Structure, the Software Architecture and the Human Activity, in order to provide an understanding concerning the meaning of each concept and relation of concepts. The semantical specification is direct to the Enterprise Structure and reflected in the Software Architecture by means of a “meaning” to the IX, BR and DE concepts that remains valid to the User Interface, Business Logic and Database layers. The Ideology, Enterprise Structure and Software Architecture concepts relations are presented in Figure 13.
Figure 13. The GOALS Language Structure.
Figure 13 presents the Enterprise Structure and Software Architecture concepts meta-model (considering the M2 level of the OMG modeling infrastructure), using UML classes which stereotype is the concept’s symbol, and the dependency relation is represented using a filled line (instead of a dashed line), for the purpose of meta-model interpretation. All the relations are of many-to-many, except for the one-to-one (1 to 1) relation of UT and AS. The relation of UT and AS is defined as of one-to-one (identified as Software Architectural Support) in order to promote business and software organization and traceability, establishing that when an actor performs a UT he does it by using a single AS, which implementation must provide all the desired system behavior. The Software Architectural Support is further detailed in Sections: 3.2.2. User Task (UT), 3.3.1. Aggregation Space (AS), 3.3.2. Interaction Component (IC), and 3.3.3. Interaction Object (IO). The remaining concepts are presented in the remaining sections.
3.1.1. Semantics
The semantics of the language is provided by means of the Ideology (structure of semiotic concepts) presented in Figure 13, which states that: an enterprise is an organization that has a certain ideology based on its purpose for the surrounding society, considering or not the related cultural premises. The ideology is based on certain beliefs and principles, which should drive the enterprise towards achieving success (its goals). These principles should drive the wisdom which users apply when carrying on their tasks, as they are materializing the enterprise’s beliefs, and should also be based on existing knowledge, which should be structured by means of
syntagmatic relations, relations which are then composed of other paradigmatic and syntactic
relations of business concepts. Paradigmatic relations are (complex) relations which are based on syntactic relations between business concepts of the enterprise. The ideology targets project team focus. The ideology and the GOALS conceptual approach is further presented in Appendix A – The Goals Conceptual Approach.