Thesis (M.Sc.) - Carleton University, 2003. / Includes bibliographical references (p. 135-138). Also available in electronic format on the Internet.

Made available in DSpace on 2014-06-12T15:57:56Z (GMT). No. of bitstreams: 2 arquivo3237_1.pdf: 1530844 bytes, checksum: dcdb6221a7c974cbfc9e96c7629001ef (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Conselho Nacional de Desenvolvimento Científico e Tecnológico / Atualmente, arquitetura baseada em componentes é a abordagem mais utilizada no desenvolvimento de softwares complexos; esta tem como principal objetivo a atribuição dos requisitos da aplicação aos componentes. Uma das técnicas mais difundidas para especificação de requisitos é a utilização de Casos de Uso. Em geral, arquiteturas de software baseadas em componentes resultam em implementações onde o código relativo a um caso de uso está espalhado e entrelaçado em diversos componentes do sistema, caracterizando um crosscutting concern. Isto ocorre porque técnicas tradicionais, como Orientação a Objetos (OO), não oferecem mecanismos que sejam capazes de modularizar este tipo de concern. Recentemente, novas técnicas de modularização como aspectos, mixins e classes virtuais, foram propostas para tentar resolver este problema. Estas técnicas podem ser usadas para agrupar o código relacionado a um único caso de uso em uma nova unidade de modularização. Este trabalho analisa qualitativa e quantitativamente o impacto causado por este tipo de modularização de casos de uso. Nós exploramos duas técnicas baseadas em Orientação a Aspectos (OA): (i) Casos de Uso como Aspectos - onde utilizamos os construtores de AspectJ para isolar todo código relativo à implementação de um caso de uso em um aspecto; e (ii) Casos de Uso como Colaborações Plugáveis - onde usamos os construtores de CaesarJ para modularizar implementações de casos de uso através de uma composição hierárquica de colaborações. Nós executamos dois estudos de casos onde comparamos as implementações OA de casos de uso com sua implementação OO. No processo de avaliação extraímos métricas tradicionais e contemporâneas incluindo coesão, acoplamento e separação de concerns e analisamos modularidade em termos de atributos de qualidade de software como: plugabilidade, rastreabilidade e suporte para desenvolvimento em paralelo. Nossos resultados indicam que modularidade é um conceito relativo e sua análise depende de outros fatores além do sistema alvo, das métricas e da técnica aplicada

Software Inspection is an effective and efficient method aiming at discovering faults within software artifacts early in the development lifecycle. The success of software inspections is highly dependent on reading techniques that guide the reviewer through the individual inspection. In other words, reading techniques help the reviewer during the inspection process. In this thesis a quite new reading technique, namely usage-based reading, is further evaluated. A reviewer who applies usage-based reading is guided by a set of prioritized use-cases. Hereby the use-cases are ranked according to their importance from the point of view of the user. Thus, the reviewers inspection effort is focused on the parts of the document that concern the most important functionality from the user’s perspective. The particular goal of this study is to figure out whether time-budgets assigned to each use-cases lead to improvements in inspection performance expressed in terms of efficiency, effectiveness and fault content. This concept is called time-controlled reading. The time-budget determines that a particular use-case must not be inspected longer than a certain number of minutes. Initially the assumption was made that time-budgets lead to performance improvements because the reading process can be better planned in forehand, that means most time is spent on the most important use-cases and all use-cases are utilized within the given inspection time. However, the result of this study contradicts that assumption. I found that both techniques are equally efficient and effective and that they find the same fault content. The reason for this is that the techniques are still quite similar and that the timebudgets assigned to the use-cases did not allow the subjects to thoroughly investigate the use-cases because they struggled with the unknown application domain. This is at least the case for lower ranked use-cases with smaller time-frames. As a consequence of this, one can claim that the results might have pointed in favor for time-controlled reading when people familiar with the application domain would have done the same experiment. / kai-petersen@gmx.de

Blockchain was first described in 1991 by Stuart Haber and Scott Stornetta as a methodology to timestamp documents and became popular with the introduction of cryptocurrency in 2008. A blockchain can be both public and private and is often described as a special ledger (like a spreadsheet) with five distinctive features. (1) It is distributed, with no central database that if a copy is corrupted others can replace it. Although each participating member on the blockchain has access to the database, there is no single controller of the information. Every member can verify transactions directly without involving intermediaries. (2) Transactions are peer to peer. There is no central node for transactions. Each peer stores and forwards transactions to all other peers. (3) It is transparent, with all transactions visible in the blockchain. Members are given access to the blockchain and all nodes of the transaction. (4) It is immutable. Once a transaction is created in the chain and the accounts are updated, it cannot be altered. (5) It is based in cryptography, the connection of the blocks is cryptographically secured, and the last line of the block is added as the first line in the next block. Each block is connected to the preceding chain making the record chronological and permanent. Furthermore, the blockchain can be programmed to include rules that activate transactions between nodes. Blockchain technology expedites and solves many business challenges. For example, blockchain technology can be used for payment processing, fraud detection, supply chain management, and verification of ownership. Blockchain technology continues to gain recognition by consumers and companies promising to disrupt existing centralized establishments while improving transparency and increasing accountability. This special session has several objectives. First, we will discuss blockchain technology and how it functions. Second, we will introduce cases of how industries are using this technology. Finally, we will propose a research framework that corresponds with four distinct exchange relationships: consumer-to-consumer, firm-to-firm, firm-to-consumer, and consumer-to-firm.

There are many different details to consider for developers when creating a new product. Many believe that the functions is the most important. However the question about how the products User Experience should be handled gets more and more important. Because of that there are lots of tests before every launch to ensure that the product gets a better welcoming with the customers. The purpose with this study was to create a overview for how to create a better User Experience. We have created a guideline in this topical subject through creating a methodology to follow. This was done because of the difficulty to follow the current guidelines, and especially from those who really don´t know the subject. This study was based on previous research with a qualitative data collection method. We did our study from the eyes of a case business where we had interviews to get their opinions about User Experience and methodologies that already exists. The information that were used as method for the selection of informants because it was important for us that the informants knew what they were talking about. The purpose of the empirical data was to conclude which parts that were necessary to include in a methodology to get a more advanced User Experience but also why it is important. With this information we could give our version of a methodology to create a User Experience that fit in different projects. The results of the study contain the parts that we thought was important for creating a methodology that the developers could use. These were Design, UX-design, User Behavior, Usability and Human Computer Interaction that we later compiled to different phases in our methodology for User Experience. Furthermore when we concluded the phases for our methodology and these were Understanding where the developers shall create an understanding about what the user really wants. Research where you research what techniques that should be a part of a modern product. Sketch where you work from what the customer wants to get prototypes and test them to get their opinion. Design where you confirms which of the prototypes you will use in a completed design. Implementation where you create the product. The last phase is Evaluate where you do usability testings continuously to know that it is really working.

Software patterns provide solutions to recurring design problems, provide a way to reason about the quality attributes, and support stakeholders in understanding the system. Naturally, the use of software patterns emerges from the requirements of the software. Use Cases have been a traditional and authentic approach to document these requirements. We propose a way to mine these patterns by sing use cases and advocate their significance in saving resources and time. For this purpose, an open-source system is discussed and four design patterns are mined with the help of use cases elicited from the documentation and literature available for the selected system. Patterns mined in this system are then document in GOF format.Furthermore, the consequences of few patterns on quality attributes are studied and an additional design pattern is proposed to improve the quality of the system. / Folkspark Vägan 15:11 ,372 40 Ronneby ,Sweden

Software patterns provide solutions to recurring design problems, provide a way to reason about the quality attributes, and support stakeholders in understanding the system. Naturally, the use of software patterns emerges from the requirements of the software. Use Cases have been a traditional and authentic approach to document these requirements. We propose a way to mine these patterns by sing use cases and advocate their significance in saving resources and time. For this purpose, an open-source system is discussed and four design patterns are mined with the help of use cases elicited from the documentation and literature available for the selected system. Patterns mined in this system are then document in GOF format.Furthermore, the consequences of few patterns on quality attributes are studied and an additional design pattern is proposed to improve the quality of the system. / Folkparksvägen 15:11, 372 40 Ronneby,Sweden

Målet med examensarbetet var att ta fram en kravspecifikation till KTH:s och ICT:s webbportal avseende utökning av tjänster för förmedling av sommarjobb, mentorskap, studiebesök och projektidéer. Syftet är att beskriva hur de fyra tjänsterna kan fungera i interaktionen mellan användaren och webbportalen. Det hela sammanställdes i en kravspecifikation med hjälp av användarfall. Metoden som valdes för att genomföra arbetet var aktionsforskning. Första steget i metoden var att studera webbportalen och sedan genom intervjuer och diskussioner ta fram användarfallen. Analysen av resultaten visar att ingenting saknas gällande funktionaliteten hos tjänsterna, men det skulle vara bra med ytterligare validering genom att diskutera kravspecifikationen med någon kunnig inom användarfall. / The goal of this paper was to produce a requirements specification for KTH:s and ICT:s web portal regarding the extension of the services intermediation of summer job, mentoring, study visits and project ideas. The purpose of the paper is to describe how the four services can function in the interaction between the user and the web portal. This was compiled into a requirements specification consisting of a number of use cases. The method chosen to conduct the research was action research. The first step of the method was to study the web portal and then through interviews and discussions create the use cases. The analysis of the results shows that nothing is missing regarding the functionality of the services, but it would be good with further validation by discussing the requirements specification with someone knowledgeable in the field of use cases.

In this thesis, a service oriented decomposition approach: Use case Driven Service Oriented Architecture (UDSOA), is introduced to close the gap between business requirements and SOA (Service Oriented Architecture) design by including business use cases and system use cases into decomposition process. The approach is constructed upon Service Oriented Software Engineering (SOSE) modeling technique and aims to fill the deficits of it at the decomposition phase. Further, it aims to involve both business vision and Information Technologies concerns in the decomposition process. This approach starts with functional top-down decomposition of the domain. Then, business use cases are used for further decomposition because of their high-level view. This connects the business requirements and our SOA design. Also it raises the level of abstraction which allows us to focus on business services. Second step of the SOA approach uses system use cases to continue decomposition. System use cases help discovering technical web services and allocating them on the decomposition tree. Service oriented analysis also helps separating business and technical services in tightly coupled architecture conditions. Those two steps together bring quality in to both problem and solution domains.

Submitted by Divisão de Documentação/BC Biblioteca Central (ddbc@ufam.edu.br) on 2017-08-24T13:19:45Z No. of bitstreams: 2 license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Reprodução Não Autorizada.pdf: 47716 bytes, checksum: 0353d988c60b584cfc9978721c498a11 (MD5) / Approved for entry into archive by Divisão de Documentação/BC Biblioteca Central (ddbc@ufam.edu.br) on 2017-08-24T13:19:59Z (GMT) No. of bitstreams: 2 license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Reprodução Não Autorizada.pdf: 47716 bytes, checksum: 0353d988c60b584cfc9978721c498a11 (MD5) / Made available in DSpace on 2017-08-24T13:19:59Z (GMT). No. of bitstreams: 2 license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Reprodução Não Autorizada.pdf: 47716 bytes, checksum: 0353d988c60b584cfc9978721c498a11 (MD5) Previous issue date: 2017-06-09 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Use Cases (UCs) have become an important artifact for the specification of software requirements. However, there are several difficulties that prevent students and software engineers from specifying UCs correctly. In order to explore and understand the difficulties in modeling diagram and specify UCs, we carried out four empirical studies with 195 participants. We present in this thesis a model about the difficulties in the modeling of UCs found in the studies carried out. The model presents the difficulties in diagram and specification UC that were classified into categories. First, we present the categories related to the diagram (D), which identify: (D-I) the actors of the system, (D-II) the use cases of the system, (D-III) generalization relationship, (D-IV) included and extend relationship; and categories related to the use-case specification (E): (E-I) abstraction of requirements, (E-II) flows of UC, (E-III) business rules, (E-IV) References of flows and business rules, (E-V) Pre- and Post-condition and (E-VI) dependence of other UCs. This on research is based on an evidence-based methodology, we executed procedures of the Grounded Theory (GT) method to analyze the data; and we use the Exploratory Factor Analysis (EFA) to evaluate the constructed model. The model was evaluated and it showed that the presented difficulties occur with more than 50% of the participants. We used EFA to identify possible factors with correlated difficulties. The EFA did not show that some of the difficulties grouped in the categories defined for the model are correlated. Through the obtained results from the empirical studies, the current version of the model can be considered valid to represent the perception of the participants about the difficulties occurred in diagram and specification of UC. In addition, the model serves as a basis for future research in the field, as well as support for the suggestion of practices to improve the teaching / learning process of students in modeling UC. / Casos de Uso (Use Cases – UCs) tornaram-se um importante artefato para a especificação dos requisitos de software. No entanto, há várias dificuldades que impedem estudantes e engenheiros de software de especificarem UCs de forma correta. Com o objetivo de explorar e entender as dificuldades em modelar diagrama e especificar UCs, foram realizados quatro estudos experimentais com 195 participantes. Esta dissertação apresenta um modelo sobre as dificuldades na modelagem de UCs encontradas nos estudos realizados. O modelo apresenta as dificuldades relacionadas a modelagem do diagrama e especificação de UC. Estas dificuldades foram classificadas em categorias. Primeiramente, serão apresentadas as categorias relacionadas ao diagrama (D): (D-I) Identificar os atores do sistema, (D-II) Identificar os casos de uso do sistema, (D-III) Relacionamento de generalização e (D-IV) Relacionamentos extend e include. Por fim, as categorias relacionadas a especificação (E): (E-I) Abstração dos requisitos, (E-II) Fluxos do UC, (E-III) Regras de negócio, (E-IV) Referências de fluxos e Regras de negócio, (E-V) Pré e Pós-condição e (E-VI) Dependência de outros UCs. Esta pesquisa fundamentou-se em uma metodologia baseada em evidências, a análise dos dados foi conduzida utilizando procedimentos do método Grounded Theory (GT) e para a avaliação do modelo elaborado utilizou-se a Análise Fatorial Exploratória (AFE). O modelo foi avaliado e mostrou que as dificuldades apresentadas ocorrem com mais de 50% dos participantes. Utilizou-se a AFE para identificar possíveis fatores com dificuldades correlacionadas. A AFE mostrou a correlação entre certas dificuldades agrupadas nas categorias definidas para o modelo. Através dos resultados obtidos dos estudos experimentais, a versão atual do modelo pode ser considerada válida para representar a percepção dos participantes sobre as dificuldades ocorridas em diagrama e especificação de UC. Além disso, o modelo serve como base para futuras pesquisas na área, bem como no apoio à sugestão de práticas para melhorar o processo de ensino/aprendizagem dos alunos em modelagem de UC.