iStar@ER 2019 - Discussion

iStar Workshop Discussion Session

John:
- Ethical Requirements: it is important to develop work on ethics, especially connected to AI systems.
- Coping with Uncertainties - we must deal in smarter ways with the uncertainties: fulfilling a goal a percentage of the way; also, having a way to make more flexible for which situations it is important to fulfil them in different degrees.

Eric:
- i* was inspired on AI, which at the time had mostly to do with Planing: goals & plans. One important question is: is there another version of i* for the new kinds of AI systems, more tuned with Data.
- another important area that we should target is argumentation, and this is connected to the ethics, already mentioned by John. This needs to include Belief, which is already present at some dialects of i*
- we also need transparency to help explain the decisions and keep the systems ethical.

Xavi:
- i* 2.0 - there is a strong diversity regarding how we work, and this hampers the way we can interact, and develop tools. Today, we have seen many works that target clarification and unification of the different views. This is a problem we have not solved yet and I am affraid that we will go to i* 3.0 without actually finishing up i* 2.0.
- lack of empirical evidence. We must target this problem! We cannot be guided by gut feeling. We really need to be stronger in providing scientific evidence.

Renata:
- In order to cope with the first topic raised by Xavi, se need a plan. After we released the i* 2.0 standard, the work on the standard stopped. We should get back to it with a set of well-defined steps. And perhaps, we should start small. I guess this is one of the messages of today's presentations here. If we are able to precisely define what a goal is and what actors are, we will be taking good steps towards providing a subset of usable concepts to i* users, and we will be able to relate and interoperate with other communities as well.

Jaelson:
- I would like to undsrstand why we are not attracting so much users anymore. In the past, we had two-day workshops. Today, I was already happy that we had a full day one. I think we should provide resources to the users. The i* wiki seems not to be enough and we should provide ways for people to take what the i* community produces and use. Moreover, we must provide ways for people to understand what are the trends, before coming to the next i* workshop.

Vítor:
- I would like to know what kind of use it has been done in industry. Perhaps understanding how they use it will provide us with new input to make it better.

MREBA@ER 2019 - Creation of Multiple Conceptual Models from User Stories: A NLP Approach - By Abhimanyu Gupta, Geert Poels, and Palash Bera

Creation of Multiple Conceptual Models from User Stories: A NLP Approach
By Abhimanyu Gupta, Geert Poels, and Palash Bera

From User Story, this works proposes the generation of four different types of conceptual models: two structural ones (Class Diagram and Use Cases) and two Behavioral ones (Sequence Diagram and BPMN).

He presented a Metamodel modeling User Story elements.

He made a Demo during the presentation, showing the generation of these models from a set of 6 user stories.

Then, he explained the NLP approach he used, composed of different rules for each type of element from the Metamodel.

*There are still a lot of limitations to be overcome in this work. In particular, it was mentioned that it is not possible to go from user stories to complete conceptual models of any kind.

MREBA@ER 2019 - Towards a Catalog of Goals for Strategic Coopetition - By Vik Pant and Eric Yu

Towards a Catalog of Goals for Strategic Coopetition - By Vik Pant and Eric Yu

Coopetition - Cooperation and Competition.
This is already a reality in the business market. Companies need Win-Win Models 

They propose catalogues of goals for this context: one goal tree of competition; one goal tree of cooperation.

Source information in online bibliography: they link their catalogue goals to the available bibliography to provide context and examples.

Top level goals are similar in both competition and cooperation goal catalogues. As much as you go to the leaves, the goals become very different.

To build the catalogues, they followed a exploratory research protocol.
*A good idea for the future is to approach it with systematic review.

They published in another paper the action research methodology they used in the case study. In this paper, they focus on the what, rather than the how, thus publishing another perspective of the same case study.

Limitations: deal with conditionals; temporal aspect. They dealt with that by etending the language.
*Why not combining i* with other languages that are more adequate for that kind of modeling.

Other limitations pointed out during Q&A:
- having either green or red (achieve/not achieve)
- having a case study where different actors compete and cooperate. It is not a real coopetition case.

Git Tutorial - Jorge D.R. Medina - Unitn/Ingegneria del Software II

Slides here, show all commands in detail

Interesting online tutorial - Learn Git Branching

Git General Commands:

·      git init – to create a new git repository on your current folder

·      touch <name of the file> – create a file

·      git add <name of the file> - add a file that is already in the folder to the git staging area. If you do not specify which branch, it will add to branch master

·      git status – show the status of your files

·      git stage <name of the file>

·      git commit <name of the file>

·      git diff <name of the file> - shows what has been changed in a particular file. It does not work for staged files.

·      git diff -- staged <name of the file> - shows what has been changed in a particular file. With the --staged parameter, it now works for staged files.

·      git add . – adds everything that changed in the directory to the repository

·      git commit -v – shows what you changed after the commit is executed.

·      Git commit -m <commit message> - add the commit message in the command line and not the editor.

·      git .ignore – creates a text file where you can write the names of files and folders to be ignored by git (you may even write *.eu to ignore files of certain extensions)

·      git rm <name of the file> – removes a file from git repository and physically from the disk.

·      ls -1

·      git rm --cache <name of the file>  - removes a file only from the index, not physically from the disk

·      git log --pretty-=oneline – to view all commits

·      git show – to view the last commit

·      git show <hash> - to view a particular commit

·      git tag -a <name of the commit> -m <message> <hash> – to associate a name and a message to a particular commit. If you do not specify a hash, it will be the last ones.

·      git tag – to view the tags I have

·      git ls-files – to view what is in the git directory

Branching Commands

A branch is just a file with a hash identifier.

The modifications (snapshots) also have a hash identifier. They are more compact “delta files”.

·      git branch – shows the branches you have

·      git branch <name of the branch> - create a new branch. Before doing this, we need at least one commit.

·      git checkout  <name of the branch>- move to a branch

·      git checkout -b <name of the branch> - creates a new branch and moved to it

·      git merge <name of the branch> - merges the branch indicated by <name of the ranch> to the merge where you currently are.

Working with remotes

·      git remote add origin <name of the new repository at GitHub>

·      git push -u origin master – push the content of a repository to your GitHub repository. Then, you should enter your GitHub name and password. In the command line, you will have some statistics about your repository. The “-u” parameter means that next time you make push, you must only use the command git push, and Git already knows that you want to push the whole repository there.

·      After doing git remote and git push (two previous topics), you must refresh the GitHub page to see the modifications.

·      git pull origin master – pulls files from the GitHub directory to your local machine.

Branching model - Gitflow

When you work on teams, the team should have some kind of convention regarding branching among other things.

Gitflow is a development model that defines a strict branching strategy centered around the idea of releases.

The Gitflow model prescribes different types of branches

• Master: this is a Versions branch
• Develop: branch created from the Master to contain the stable developed features.
• Feature: created from the Develop Branch for each feature being developed (not stable). When ready, the feature branch should be merged into the develop branch.
• Release: when all features for the release are ready, a branch is created from the Develop branch. Then, the Release branch merges into the Master branch.
• Hotfix: created from the Master branch to fix bugs very quickly. These are critical bugs that should be fixed immediately to guarantee the application to keep operating. Minor bugs can be fixed in the Feature branch. If there is more than one critical bug and they are related, they may be fixed in the same Hotfix branch. Otherwise, you should have distinct Hotfix branches. Hopefully, that will not be common.

Advanced commands:

• git rebase – a set of commands are executed to prepare the branches for a fast forwarding merge (see slides + simulation on Learn Git Branching
• git stash - allows us to store half-done work without doing a commit. It is as if it saves a snapshot of what we've done so far and waits for us to come back to it. If we do git status, we see an empty list
• git stash list - allows us to check the stashes we have
• git stash apply stash@{0} - get back to the stash identified by "stash@{0}"
• git rebbase -i - interactive rebasing allows us, among other things, to squash multiple commits into one.