The paper deals with the use of the design thinking approach when creating architectural views which consider motivation and the main goals set for the design phase of the software intensive system (SIS) development. In this case, any architectural view is formed with the help of the system of conceptual equations, which can be solved via the abductive reasoning carried out by a designer. In terms of automated design thinking, such reasoning helps to define constructive relations among motives, goals, and requirements integrated into the corresponding view. For all the views included in an architectural description, such relations are useful to combine, visualize and interpret as motivationally targeted views demonstrating which architectural decisions match the intended goals.
Professionally mature development of a modern SIS is unthinkable without the mandatory construction and the operational use of an architecture description (AD). This artifact is a conceptual version of a SIS reflecting its understanding as integrity, which is demanded by stakeholders at all the stages of the SIS lifecycle. Being a sample of verified structures and embedded understanding, the AD plays an executive role providing correspondence between this sample and the current state of the SIS in the design process. It should also be highlighted that this version is the first (the earliest) representation of a SIS as integrity and can be tested to detect dangerous semantic errors.
The abovementioned advantages of using ADs were the reasons for accumulating
the experience of architectural modeling intensively that was generalized in several
standards; ISO/IEC/IEEE 42010: 2011 is among them. This standard assumes that an
AD is the system S({Vj}) of “architectural views” {Vj} which are built based on
corresponding “viewpoints” {VPk}. Each viewpoint specifies “the conventions (such as
notations, languages, and types of models) for constructing a certain kind of view.
That viewpoint can be applied to many systems. Each view is one such application”
[
Thus, any viewpoint can be interpreted as a certain guide with necessary means that help to build the corresponding view or a set of views, any of which expresses a certain interest (concern Ci) in a visualized form that is understandable for a certain stakeholder involved in the corresponding project. Therefore, any new viewpoint is an artifact that should be developed, starting with the decision to take into account some important concern (or a set of concerns), the viewpoint for which is absent or must be modified.
In this paper, we offer an architectural approach applied in the ontological maintenance toolkit. The toolkit can be used when developing a certain SIS which’s lifecycle begins with vague intentions. In this case, firstly, the developers must understand the work beforehand, presenting it as integrity, i.e. as a task that needs to be solved.
The remainder of the paper is structured as follows. The features of design thinking in the considered version of architectural modeling are presented in Section 2. Section 3 points out related works. The approach in the offered viewpoint is described in Section 4. In Section 5, we present the example of a motivationally targeted view, and the paper is concluded in Section 6. 2
The standard ISO/IEC/IEEE 42010: 2011 envisages that any “concern” may be
architecturally described with a coordinated group of useful “points of view” and
corresponding “views”. For example, the authors of [
Another trick is given in the publication [
Another means of accounting and materializing “concerns” is their specifications,
i.e. the distribution of a set of types and the integration of a set of (distributed)
constituent concerns within the framework of “architectural types”. Thus, they associate
an “aspect-oriented” representation and the materialization of concerns [
The real practice of architectural decisions is discussed in the industrial case study
published in [
As far as our version of the architectural approach to the ontological maintenance
of solving project tasks is concerned, one more group of related works should be
considered. These works include papers on the subject area of ontologies. In this group,
we highlight the paper [
The application allows processing short text units (i.e. discourses) related to a certain software project with the help of a project ontology.
Processing a discourse is a unit of ontological support for the project. We consider a discourse to be a short text consisting of 2-3 sentences which is a reasoning unit concerning the project. The text may include the requirements to the system or its specifications; in a particular case, it may also be the project general task statement.
The application is integrated into the instrumental environment OwnWIQA with the help of pseudo coding tools. 3.1
At the moment, the application has the following structure (see Figure 1). Various interface forms are marked with blue circles; functional and auxiliary modules (files, external applications, etc. used by our application) are marked with yellow circles.
Each interface form is designed with the help of the prototyping tools of the OwnWIQA instrumental environment which allow adding some simple, functional units to the form, such as: buttons (with the ability to link it to a pseudocode procedure); text fields (the text can be written to the variable and used by a pseudocode procedure); other graphic elements.
Moving from one interface form to another is implemented with the help of buttons which call the following pseudocode procedure: DD_Load(“diagram_file_path”) // open the interface form from a file DD_LoadEvents(“events_file_path”) // load events linked to the units of the form FINISH Let us know describe the functionality of the interface forms and modules one by one. 3.2
The Architectural Views interface form (see Figure 2) shows all the possible views on a discourse being processed. It can be a text saved in a file or the question-and-answer memory of the WIQA environment. It can be a list of ontological concepts found in the discourse. It can be a semantic scheme built in the graphic editor of the WIQA environment and so on.
The changelog file mentioned in the “File view” element has the following meaning: each time the text of a discourse changes, one should add the changes to the changelog file; if there are any changes in the text of discourse, one should add the following record at the end of the file: “[HH:MM DD.MM.YYYY] [Text of discourse]”. 3.3
The Base View form can be considered to be the main form which a designer deals with. It shows the current version of the discourse as well as all the important conceptual items related to it. At the bottom of the form, one can see all the instruments and additional modules used during the ontological support activity.
Action on element Save the text of the current discourse to the changelog file.
Move to the “Architectural views” interface form.
Show the description of the required designer skills.
Move to one of the Activity interface forms according to the workflow.
Open a text file containing changelog of the current discourse.
Move to the “Task statement” interface form.
Open a text file describing possible techniques to process a discourse.
Move to the “Checkpoints” interface form.
Open the Ontology module in the OwnWIQA environment.
Move to the “Program agents” interface form.
Move to the “Language processing tools” interface form.
Move to the “Dictionaries” interface form.
Move to the “Pseudocode programs” interface form.
The next interface form plays a substantiating and theoretical role. It describes the task statement, which was used to develop the ontological support toolset (see Figure 4). Our toolkit includes some activities which can be fully automated. So, we decided to use software agents for that purpose. The agents perform such activities as splitting a text into wordforms, normalizing them, retrieving collocations, filtering out stopwords, discovering pairs of semantically related text fragments and others. When clicking on each icon, a designer can launch the corresponding agent which will immediately start processing the current discourse and print the result.
Agents are also used during the main workflow and, in that case, are launched automatically as soon as there are data to process. The interface form in Figure 5 allows launching each software agent manually for demonstration purposes. Language processing tools are external auxiliary programs integrated into the ontological support toolset to raise the efficiency of text processing.
We use part-of-speech taggers and parsers for the Russian and the English languages to extract linguistic information from a text and use it for our purposes.
The corresponding interface form is available in Figure 6.
Interface element (icon)
The next interface forms were designed to demonstrate all the auxiliary dictionaries that the ontological support tool uses. Since our application allows processing texts both in English and in Russian, first of all, a user has to choose the language (see Figure 7).
For each language, we have three types of dictionaries: stop-word dictionaries, term dictionaries (can be optionally added by a user if he/she is working with some specific domain) and tag dictionaries (used for retrieving semantic relations). The interface form showing dictionary types for the English language is presented in Figure 8. Tag dictionaries Term dictionaries
Move to the “Tags dictionaries” interface form.
Open the window to connect term dictionaries if needed.
We designed a separate interface form for tag dictionaries so that a user could check which tags the tool uses to retrieve semantic relations from a text and add or remove some of them if needed. Tags are such words or collocations that signalize and highlight if there are relations of a certain type in the current phrase.
At the moment, the tool can retrieve two types of semantic relations: part-whole and casual ones because they are most useful for building prototypes. Correspondingly, four types of tags are available in the form (see Figure 9). Along with the modules in C#, we use separate procedures and functions developed with the help of the pseudocode programming module of the OwnWIQA instrumental environment. This helps to make our toolset more flexible since any pseudocode procedure can be integrated into the tool without changing its architecture.
Furthermore, pseudocode programs have simple syntax and can easily be understood by any person, which also makes the work of the toolset more transparent.
used for automated building semantic schemes [
At various stages of processing a discourse, different lists are created. Lists are usually the results of the software agents’ work, i.e. they can be used both as the input and the output data of these agents. Figure 11 shows all the possible lists a user can deal with. current discourse linked by a causal relation. 3.10
This subsection describes the workflow that a user of the ontological support tool has to undergo to process one discourse.
Checkpoints. While being processed, a discourse can often be edited and corrected (if any errors are revealed). Thus, it is important for a user to have an opportunity to track all the changes in the discourse and revert to one of its previous versions if needed.
The interface form in Figure 12 shows all the eight steps a user has to undergo one by one when working with a discourse. Apart from that, at any phase he/she can easily go back to the previous one.
The form also shows the status of each phase which can have three states: to do (if a user has not started working on it yet); in progress; done.
Double click on each phase icon starts a corresponding activity. Each activity will be described further.
Establish a link to the project. While a project is being designed, its language is being constructed. This language is unique for each project. Moreover, the project language is changing from phase to phase and requires to be registered. To register the project language, we use a separate dictionary in the ontology module of the OwnWIQA environment. The dictionary is constructed in the form of ontology and allows storing concepts related to the current project, their definitions as well as different types of semantic relations between them.
So, the first step of processing a discourse is to establish a link between the discourse and the project it relates to, i.e., choose the corresponding dictionary in the ontology module (Figure 13 shows the interface form designed for that purpose). If it is the first discourse a user deals with within the current project, a new dictionary has to be created. From this point on, all the changes made in the discourse will be stored in this dictionary. Otherwise, a corresponding dictionary has to be selected
At this phase (as well as at all the further ones) a user can make any changes in the text of discourse and see the changelog if needed.
After establishing a link to a project, one can click “Next” and move to the next phase or click “Back” and move back to the checkpoints. Specify and track concerns. When working on a project a designer may need to track some quality indicators (for example, understandability, testability, flexibility, and others), i.e. concerns or requirements of the main project stakeholders. Each concern can have its membership function which shows how its quality lever changes at different project design phases.
Our tool allows tracking these concerns and saving them in a separate group of the
project ontology. The principles of this activity, as well as some examples, are given
in paper [
The algorithm of revealing semantic relations is based on tags which “highlight” relations of a certain type in the text.
After the relations are revealed, lists of related phrases are matched with the list of potential concepts got at the previous phase – as a result, we get a list of related concepts. Match discourse with ontology. At this phase, all the concepts revealed form the text of discourse are matched with the project ontology. If the project ontology already contains any of them, all the information related to these concepts (definitions, related concepts, etc.) is retrieved from the ontology and shown to the user, so that he/she could correct possible mistakes and inaccuracies. Refill project ontology. Finally, new information should be added to the project ontology. This can be done either manually or with the help of the lists of potential concepts and relations created at previous phases. Creating and using architectural models is the key factor in the successful development of modern SISs. Such models register the necessary understanding, reflecting corresponding essences as integrity, which is especially important for architectural views combining semantized graphics with necessary symbolic descriptions written in the project language.
In the offered approach, a designer can develop any view in the process of solving an architectural task with the use of automated design thinking, means of which are embedded into the WIQA toolkit. Among these means, the specialized graphical editor plays a very important role. This editor helps to detailed visualized structures that express not only separate views but also their programmed compositions.
We apply this approach to improve the existed version of the ontological maintenance (OM) embedded into the WIQA toolkit. The current version of the OM is implemented in the prototype form, graphical elements of which are created by means of the graphic editor with indexed references when it is necessary. In other words, functions of the OM are accessible to a designer via interfaces any of which is the prototype version of the corresponding architectural view on the OM.