Classes de Desenho - Licenciatura em Engenharia Informática PDF

Classes de Desenho Licenciatura em Engenharia Informática ESTSetúbal - IPS 2024/25 Nuno Pina Gonçalves [email protected]  Agenda 2  Diagrama de classes em UML  Relacionamentos  Associação ◼ Agregação e compo...

Classes de Desenho Licenciatura em Engenharia Informática ESTSetúbal - IPS 2024/25 Nuno Pina Gonçalves [email protected]  Agenda 2  Diagrama de classes em UML  Relacionamentos  Associação ◼ Agregação e composição  Generalização/Especialização © Nuno Pina 2024  Atividades de um processo de 3 desenvolvimento de SI  Análise dos processos organizacionais  Requisitos  Análise (Especificação funcional e não funcional do sistema)  Desenho (Arquitetura do software, modelos de conceção)  Implementação (código)  Validação, integração e instalação  Manutenção © Nuno Pina 2024  Enquadramento da Análise 4 As fases de Análise e de Requisitos estão fortemente interligadas e muitas vezes parcialmente sobrepostas. Requisitos Os termos utilizados de ambas as fases são do domínio do problema. É na fase de Análise que muitas vezes se descobrem falhas no levantamento de requisitos Análise (omissão e distorção). © Nuno Pina 2024  Objetivos da Análise 5  Capturar uma visão geral do problema.  Identificar e especificar as entidades informacionais (classes) do domínio do problema.  Identificar como se relacionam as diversas entidades informacionais.  Demonstrar que é possível realizar as funcionalidades especificadas na fase de levantamento de requisitos utilizando as entidades informacionais especificadas – realização dos use cases. © Nuno Pina 2024  Entidades informacionais 6  Numa abordagem orientada a objetos, as principais entidades informacionais são representadas através de classes.  Os objetos representam instancias dessas mesmas classes e caracterizam-se por:  Identidade – Cada objeto pode ser acedido individualmente.  Estado – caracterizado pelos valores dos dados armazenados no objeto num determinado instante de tempo  Comportamento – conjunto de operações que o objeto pode efetuar. © Nuno Pina 2024  Objetos: Encapsulamento de dados 7 operações valores dos atributos  Os dados são escondidos dentro do objeto – a única forma de depositar() aceder aos dados é através de uma operação. levantar() numero = "1243"  O encapsulamento permite criar titular = "Jim Arlow" software mais robusto e permite saldo = 300.00 a reutilização de código. getTitular() setTitular() Objeto contaBancaria1 © Nuno Pina 2024  Objeto: Comunicação entre objetos 8  Nos sistemas Orientados a Objetos (OO) os objetos comunicam uns com os outros enviando mensagens.  Estas mensagens fazem com que o objeto execute uma operação.  Os objetos só conseguem comunicar se conhecerem o objeto destinatário. Objeto bancoBPI Objeto contaBancaria1 levantar( 150.00 ) O objeto bancoBPI envia O objeto contaBancaria1 responde à uma mensagem levantar mensagem executando a operação 150 euros ao objeto levantar. A operacao decrementa o contaBancaria1. saldo do objeto contaBancaria1 em 150 euros. © Nuno Pina 2024  Classes de análise 9  As classes de análise representam abstrações claras do domínio do problema. Nome da Classe Conta Bancária  Estas classes são independentes da linguagem de programação a utilizar na nome implementação. Atributos endereço  As classes de análise têm: saldo  Um conjunto de atributos de alto nível depositar()  Operações que são especificações de alto Operações levantar() nível do conjunto de serviços calcularJuros() fundamentais que a classe terá que disponibilizar  As classes de análise devem ser mapeadas dos conceitos do negócio do mundo real. © Nuno Pina 2024  Diagrama de Classes em UML 10  Como especificar as classes e relacionamentos entre classes ? Usar Diagrama de classes em UML. Representar Classes, com os atributos e operações Representar os relacionamentos entre Classes © Nuno Pina 2024  O que é um relacionamento? 11  Relacionamentos são ligações semânticas (com significado) entre elementos de modelação  Já vimos alguns tipos de relacionamentos:  entre atores e Use Cases (associação)  entre Use Cases e Use Cases («include», «extend»)  entre atores e atores (generalização) © Nuno Pina 2024  Relacionamentos entre Classes 12 Existem três tipos base de relacionamentos: 1. Associação – indica se existe algum tipo de ligação entre objetos das duas classes. 2. Generalizacão/Especializacão: relação entre classe mais geral e classe mais especifica. 3. Dependência: indica se uma classe depende de outra (a abordar na próxima aula) © Nuno Pina 2024  Relacionamento de Associação 13  Associações são ligações entre classes  Os objetos são instâncias das classes e os links são instâncias das associações associação Clube Pessoa «instantiate» «instantiate» «instantiate» link ClubeLeitura:Clube chairman jim:Pessoa © Nuno Pina 2024  Sintaxe das associações 14  As associações podem ter: nome da associação (verbos), papéis (substantivo), multiplicidade, navegabilidade Nome da associação emprega Empresa 1 Pessoa multiplicidade * navegabilidade Nome dos papeis empregador empregado Empresa 1 Pessoa * © Nuno Pina 2024  Multiplicidade 15  A multiplicidade é uma restrição que especifica o número de objetos que podem participar num relacionamento num determinado instante de tempo  Não existe multiplicidade por defeito – se não estiver expressa no modelo significa que ainda não está decidido o seu valor multiplicity syntax: minimum..maximum 0..1 zero or 1 Uma empresa emprega muitas pessoas 1 exactly 1 empregador empregado 0..* zero or more Empresa Pessoa * zero or more 1 * 1..* 1 or more Cada pessoa trabalha numa empresa 1..6 1 to 6 © Nuno Pina 2024  Exercício 1 16 1. Quantos empregados pode ter uma empresa? Empresa 2. Quantos empregadores 1 empregador poderá ter uma pessoa? 3. Quantos proprietários poderá 7 empregado ter uma conta bancária? Pessoa 4. Quantas contas bancárias proprietário 1 1..* operador poderá ter uma pessoa? 5. Quantas contas bancárias 0..* 0..* pode uma pessoa operar ContaBancária Nota: Ler o modelo exatamente como está escrito © Nuno Pina 2024  Associações e atributos 17 = endereço Casa Casa Endereco 1 1 endereco:Endereço Casa pseudo-atributo atributo endereco:Endereço  Se um relacionamento navegável tiver um papel, é como se a classe fonte tivesse um pseudo-atributo cujo nome é o nome do papel e cujo tipo é a classe destino ("target")  Os objetos da classe fonte referem-se aos objetos da classe "target" utilizando este pseudo-atributo. © Nuno Pina 2024  Associações e atributos 18  Utilizar associações quando:  A classe "Target" é uma parte importante do modelo  A classe "Target" é uma classe criada por si e que tem que ser mostrada no modelo  Utilizar atributos quando:  A classe "Target" não é uma parte importante do modelo ex. tipo primitivo como number, string, etc.  A classe "Target" é apenas um detalhe de implementação tal como um ”library component" (ex: Java util vector) ou um componente adquirido. © Nuno Pina 2024  Agregação (has-a) 19  Agregações são um tipo especial de associação no qual as duas classes participantes não possuem um nível igual, mas fazem um relacionamento “todo-parte”.  Uma Agregação descreve como a classe que representa o todo, é composta (tem) de outra classe, que representa as partes.  Para Agregações, a classe que age como o todo tem uma multiplicidade de um. © Nuno Pina 2024  Composição (has-a) 20  A composição é um tipo de agregação em que a relação do todo para as partes é mais forte do que na agregação simples.  O tempo de vida do todo é igual ao tempo de vida das partes, no entanto é possivel em qualquer altura do ciclo de vida, adicionar partes ao todo, ou retirar partes ao todo.  Ex. É possivel adicionar e eliminar items à encomenda.  A destruição do todo implica na destruição das partes.  Ex. Se encomenda for distruida (cancelada) todos os seus items o serão também.  O todo é responsável pela criação das partes  Ex. A encomenda é responsável pela criação dos vários items (linhas de encomenda).  Os objetos parte pertencem a um único todo  Ex: Um item de produto só pode pertencer a uma única encomenda. © Nuno Pina 2024  Exercício 2 21  Das situações abaixo indique quais representam relacionamentos de composição e quais são de agregação. 1. Banco e Conta Bancaria. 2. Aluno e Turma (tipo escola do 1º ciclo). 3. Carro e Motor 4. Conta Bancaria e Cartão de Débito. © Nuno Pina 2024  Agregação vs Associação 22  Usa-se uma associação entre duas classes quando estas estão conceptualmente no mesmo nivel.  Uma pessoa trabalha numa empresa.  Usa-se uma agregação quando uma classe representa o todo e outra a parte desse todo. O Carro tem rodas  A Equipa de Futebol tem Jogadores © Nuno Pina 2024  Generalização/Especialização (is-a) 23  Herança é uma relação entre classes em que umas herdam o estado e o comportamento das outras. © Nuno Pina 2024  Generalização/Especialização (is-a) 24  Uma conta bancaria é uma generalização de uma conta corrente e de uma conta poupança.  A conta agrupa o que é comum ás classes conta poupança e conta corrente: ◼ a estrutura de dados (atributos) e/ou ◼ o comportamento (métodos) ◼ relacionamentos © Nuno Pina 2024  Generalização/Especialização (is-a) 25  Um Equipamento Eletrónico é uma especialização de um Equipamento. O Equipamento Eletrónico é uma extensão, refinamento ou especialização desta, acrescentando-lhe:  mais estrutura de dados (atributos) e/ou  mais comportamento (métodos) © Nuno Pina 2024  A reter 26  Um Diagrama de classes indica os diversos tipos de objetos (classes) que existem no sistema e como estes se relacionam entre si!  Existem distintos tipos de relacionamentos entre classes: 1. Associação: indica se existe algum tipo de ligação entre objetos das duas classes. ▪ Relacionamentos todo-parte :Agregação e Composição. 2. Generalizacão/Especializacão: relação entre classe mais geral e classe mais especifica. © Nuno Pina 2024  Because learning changes everything.® Chapter 8 Requirements Modeling – A Recommended Approach Part Two - Mobility. © 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom. No reproduction or further distribution permitted without the prior written consent of McGraw Hill.  Requirements Analysis Requirements analysis specifies software’s operational characteristics. indicates software's interface with other system elements. establishes constraints that software must meet. Requirements analysis allows the software engineer to: elaborate on basic requirements established during earlier requirement engineering tasks. build models that depict the user’s needs from several different perspectives. © McGraw Hill 2  Requirements Models Scenario-based models depict requirements from the point of view of various system “actors.” Class-oriented models represent object-oriented classes (attributes and operations) and how classes collaborate to achieve system requirements. Behavioral models depict how the software reacts to internal or external “events.” Data models depict the information domain for the problem. Flow-oriented models represent functional elements of the system and how they transform data in the system. © McGraw Hill 3  A Bridge Access the text alternative for slide images. © McGraw Hill 4  Rules of Thumb The level of abstraction should be relatively high - focus on requirements visible in problem or business domains. Analysis model should provide insight into information domain, function, and behavior of the software. Delay consideration of infrastructure and other non-functional models until later in the modeling activity. The analysis model provides value to all stakeholders keep the model as simple as it can be. © McGraw Hill 5  Requirements Modeling Principles Principle 1. The information domain of a problem must be represented and understood. Principle 2. The functions that the software performs must be defined. Principle 3. The behavior of the software (as a consequence of external events) must be represented. Principle 4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Principle 5. The analysis task should move from essential information toward implementation detail. © McGraw Hill 6  Scenario-Based Modeling: Actors and Profiles A UML actor models an entity that interacts with a system object. Actors may represent roles played by human stakeholders or external hardware as they interact with system objects by exchanging information. A UML profile provides a way of extending an existing model to other domains or platforms. This might allow you to revise the model of a Web-based system and model the system for various mobile platforms. Profiles might also be used to model the system from the viewpoints of different users. © McGraw Hill 7  Use Cases Use case as a “contract for behavior” and more formal than a user story. Use-cases are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases). 1. What should we write about? 2. How much should we write about it? 3. How detailed should we make our description? 4. How should we organize the description? © McGraw Hill 8  What to Write About? The first two requirements engineering tasks—inception and elicitation—provide you with the information you’ll need to begin writing use cases. To begin developing a set of use cases, list the functions or activities performed by a specific actor. You can obtain these from a list of required system functions, through conversations with stakeholders, or by an evaluation of activity diagrams developed as part of requirements modeling. Use cases of this type are sometimes referred to as primary scenarios. © McGraw Hill 9  Alternative Interactions Description of alternative interactions is essential to completely understand a function described a use case. Can the actor take some other action at this point? Is it possible that the actor will encounter some error condition at this point? Is it possible that the actor will encounter some other behavior at this point (for example: behavior that is invoked by some event outside the actor’s control)? Answers to these questions result in the creation of a set of secondary scenarios represent alternative use cased behavior. © McGraw Hill 10  Defining Exceptions An exception describes a situation (either a failure condition or an alternative chosen by the actor) that causes the system to exhibit somewhat different behavior. Questions to ask: Are there cases in which some “validation function” occurs during this use case? Are there cases in which a supporting function (or actor) will fail to respond appropriately? Can poor system performance result in unexpected or improper user actions? © McGraw Hill 11  Documenting Use Cases What are the main tasks or functions that are performed by the actor? What system information will the actor acquire, produce or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? What are the preconditions, triggers, exceptions, and open issues? © McGraw Hill 12  Use Case Diagram Access the text alternative for slide images. © McGraw Hill 13  Class-Based Modeling Class-based modeling represents: objects that the system will manipulate. operations (also called methods or services) that will be applied to the objects to effect the manipulation. relationships (some hierarchical) between the objects. collaborations that occur between the classes that are defined. The elements of a class-based model include classes and objects, attributes, operations, CRC models, UML class diagrams. © McGraw Hill 14  Identifying Analysis Classes Examining the usage scenarios developed as part of the requirements model and perform a "grammatical parse“. Classes are determined by underlining each noun or noun phrase and entering it into a simple table. Synonyms should be noted. If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space. But what should we look for once all of the nouns have been isolated? © McGraw Hill 15  Potential Analysis Classes External entities (for example: other systems, devices, people) that produce or consume information. Things (for example: reports, displays, letters, signals) that are part of the information domain for the problem. Occurrences or events that occur within the context of system operation. Roles played by people who interact with the system. Organizational units that are relevant to an application. Places that establish the context of the problem and overall function. Structures (for example: sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects. © McGraw Hill 16  Analysis Class Selection Retained information. Potential class will be useful during analysis only if information about it must be remembered. Needed services. Potential class must have a set of identifiable operations that can change the value of its attributes in some way. Multiple attributes. Focus should be on "major" information; a class with a single attribute may be better represented as an attribute of another class. Common attributes. A set of attributes can be defined for the potential class and the attributes apply to all instances of the class. Common operations. A set of operations can be defined for the potential class and the operations apply to all instances of the class. Essential requirements. External entities that appear in the problem space and produce or consume information essential to the solution will usually be defined as analysis classes in the model. © McGraw Hill 17  Defining Attributes Attributes describe a class that has been selected for inclusion in the analysis model. It is the attributes that define the class—that clarify what is meant by the class in the context of the problem space. To develop a meaningful set of attributes for an analysis class, you should study each use case and select those “things” that reasonably “belong” to the class. What data items(composite and/or elementary) fully define this class in the context of the problem at hand? © McGraw Hill 18  Defining Operations Operations define the behavior of an object. Operations they can generally be divided into four broad categories: 1. Operations that manipulate data in some way. 2. Operations that perform a computation. 3. Operations that inquire about the state. 4. Operations that monitor an object for the occurrence of a controlling event. These functions are accomplished by operating on attributes and/or associations. Therefore, an operation must have “knowledge” of the class attributes and associations. © McGraw Hill 19  CRC Modeling Class-responsibility-collaborator (CRC) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections: 1. Along the top of the card you write the name of the class. 2. list the class responsibilities on the left. 3. list the collaborators on the right. © McGraw Hill 20  CRC Cards Access the text alternative for slide images. © McGraw Hill 21  CRC Model Review Process 1. All stakeholders in the review (of the CRC model) are given a subset of the CRC model index cards. No reviewer should have two cards that collaborate. 2. The review leader reads the use case deliberately. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card. 3. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one of the responsibilities satisfies the use case requirement. 4. If an error is found, modifications are made to the cards. This may include the definition of new classes (CRC index cards) or revising lists of responsibilities or collaborations on existing cards. © McGraw Hill 22  Functional Modeling The functional model addresses two application processing elements: 1. user-observable functionality that is delivered by the app to end users. 2. operations contained within analysis classes that implement behaviors associated with the class. UML activity diagrams can be used to represent processing details. UML activity diagram supplements a use case by providing a graphical representation of the flow of interaction within a specific scenario. © McGraw Hill 23  Activity Diagram 1 Access the text alternative for slide images. © McGraw Hill 24  Sequence Diagram 1 The UML sequence diagram can be used for behavioral modeling. Sequence diagrams can also be used to show how events cause transitions from object to object. Once events have been identified by examining a use case, the modeler creates a sequence diagram—a representation of how events cause flow from one object to another as a function of time. Sequence diagram is a shorthand version of a use case. © McGraw Hill 25  Sequence Diagram 2 Access the text alternative for slide images. © McGraw Hill 26  Behavioral Modeling A behavioral model indicates how software will respond to internal or external events or stimuli. This information is useful in the creation of an effective design for the system to be built. UML activity diagrams can be used to model how system elements respond to internal events. UML state diagrams can be used to model how system elements respond to external events. © McGraw Hill 27  Creating Behavioral Models 1. Evaluate all use cases to fully understand the sequence of interaction within the system. 2. Identify events that drive the interaction sequence and understand how these events relate to specific objects. 3. Create a sequence diagram for each use case. 4. Build a state diagram for the system. 5. Review the behavioral model for accuracy and consistency. © McGraw Hill 28  Identifying Events A use case represents a sequence of activities that involves actors and the system. An event occurs whenever the system and an actor exchange information. An event is not the information that has been exchanged, but rather the fact that information has been exchanged. A use case needs to be examined for points of information exchange. Events are used to trigger state transitions. © McGraw Hill 29  State Diagram Access the text alternative for slide images. © McGraw Hill 30  Activity Diagram 2 Access the text alternative for slide images. © McGraw Hill 31  Swimlane Diagrams The UML swimlane diagram is a useful variation of the activity diagram that allows you to represent the flow of activities described by the use case. Swimlane diagrams indicate which actor (if there are multiple actors involved in a specific use case) or analysis class has responsibility for the action described by an activity rectangle. Responsibilities are represented as parallel segments that divide the diagram vertically, like the lanes in a swimming pool. © McGraw Hill 32  Swimlane Diagram Access the text alternative for slide images. © McGraw Hill 33 Because learning changes everything. ® www.mheducation.com © 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom. No reproduction or further distribution permitted without the prior written consent of McGraw Hill.  Accessibility Content: Text Alternatives for Images © McGraw Hill 35  A Bridge – Text Alternative Return to parent-slide containing images. An illustration displays a bridge. Three circles represent the system description, analysis model, and design model. The analysis model overlaps with the system description, and the design model. Return to parent-slide containing images. © McGraw Hill 36  Use Case Diagram – Text Alternative Return to parent-slide containing images. An illustration displays a case diagram. The homeowner is connected to the three use cases of a safehome. The use cases are, access camera surveillance via the internet, configures safehome system parameters, and sets alar. The access camera surveillance via the internet is further connected to cameras. Return to parent-slide containing images. © McGraw Hill 37  CRC Cards – Text Alternative Return to parent-slide containing images. An illustration displays CRC cards. The title reads class: floor plan. The space below the title reads description. The card is further divided into two columns titled responsibility, and collaborator. The responsibility reads defines floor plan name or type; manages floor plan positioning; scales floor plan for display; incorporates walls, door, and windows, and shows position of video cameras. The collaborator reads, wall on the column corresponding to incorporates wall, doors, and windows; and camera in the column respective to shows position of video cameras. Return to parent-slide containing images. © McGraw Hill 38  Activity Diagram – Text Alternative 1 Return to parent-slide containing images. A flowchart displays an activity diagram. The diagram starts with two possibilities, camera not in use, and camera in use. If the camera in use, get current camera user, and then report camera in use and home of current user. If the camera not in use, the request camera lock. If the camera lock is available, then report camera now locked for user. If the lock is unavailable, then report camera unavailable. Return to parent-slide containing images. © McGraw Hill 39  Sequence Diagram – Text Alternative 2 Return to parent-slide containing images. The sequence diagram has four life lines which are labeled, from left to right, homeowner, control panel, system and sensors. When the system is ready the homeowner enters a password which is relayed to the control panel. The control panel begins by reading the message and then performs a compare of the password entered. When comparing the control panel sends a lookup request to the system which return a result. If the password is correct the system sends an activation request to the sensors which over a duration sends a successful activation message to the control panel which further the relays the successful activation message to the homeowner. If the password entered is wrong the homeowner has a maximum number of three tries to enter the correct password. If the three tries are exceeded the system is locked. Locked system has looped timer. Return to parent-slide containing images. © McGraw Hill 40  State Diagram – Text Alternative Return to parent-slide containing images. The state diagram shows an initial state of the process. After the key is hit the diagram shows a reading state. The reading state transitions the entered password to a comparing state. The comparing state is a shown as a class with a validate password operation. The comparing state has a loop, if password equals incorrect and number of tries greater than maximum number of tries. When number of tries exceeds maximum number of tries the comparing state transitions to a locked state. A locked state has a loop with timer greater than locked time. When timer greater than locked time the locked state transitions back to the reading state. If the password entered is correct the comparing state transitions to a selecting state. Upon a successful activation selecting state transitions back to the reading state. Return to parent-slide containing images. © McGraw Hill 41  Activity Diagram – Text Alternative 2 Return to parent-slide containing images. The activity diagram begins with an initial state. The next activity state is enter password and user ID. This initiates a condition. If a password and ID are valid and if a password and ID are invalid. If invalid, then prompt for reentry activity. This entails another condition. If input tries remain the process loops back to the initial condition at enter password and ID if no input tries remain the process reaches an end state. If in the initial condition the valid ID and password were entered the next activity is select major function here other functions may also be selected. After this next activity is select surveillance. After selecting surveillance, the user can choose thumbnail views or select a specific camera. Selecting thumbnail, leads to select specific camera thumbnails and selecting a specific camera leads to select camera icon. Both, select specific camera thumbnails and select camera icon lead to view camera in output in labeled window. This leads to prompt for another view. This leads to two condition. First exit this function which leads to a final state or see another camera which loops back to the condition under select surveillance. Return to parent-slide containing images. © McGraw Hill 42  Swimlane Diagram – Text Alternative Return to parent-slide containing images. The swimlane diagram is illustrated within a table. The three column headings of the table are: homeowner, camera and interface. The flow begins with an initial state in homeowner. The next activity state is enter password and user ID. This initiates a condition in the interface. If a password and ID are valid and if a password and ID are invalid. If invalid, then prompt for reentry activity. This entails another condition also within interface. If input tries remain the process loops back to the initial condition at enter password and ID if no input tries remain the process reaches an end state. If in the initial condition the valid ID and password were entered the next activity is select major function, under homeowner, here other functions may also be selected. After this next activity is select surveillance. After selecting surveillance, the user can choose thumbnail views or select a specific camera. Selecting thumbnail, leads to select specific camera thumbnails and selecting a specific camera leads to select camera icon. Both, select specific camera thumbnails and select camera icon lead to, the activity, generate video output, under the column camera. Generate video output leads to view camera in output in labeled window, under homeowner. This leads to prompt for another view under interface. This leads to two conditions. First exit this function which leads to a final state or see another camera which loops back to the condition under select surveillance. Return to parent-slide containing images. © McGraw Hill 43  Because learning changes everything.® Chapter 6 Principles that Guide Practice Part Two - Modeling © 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom. No reproduction or further distribution permitted without the prior written consent of McGraw Hill.  Principles that Guide Process 1 Principle #1. Be agile. Regards of your process model, let the basic tenets of agile development govern your approach. Principle #2. Focus on quality at every step. The exit condition for every process activity, action, and task should focus on the quality of the work product produced. Principle #3. Be ready to adapt. Dogma has no place in software development. Adapt your approach to constraints imposed by the problem, the people, and the project itself. Principle #4. Build an effective team. Software engineering process and practice are important, but the bottom line is people. Build a self-organizing team. © McGraw-Hill 2  Principles that Guide Process 2 Principle #5. Establish mechanisms for communication and coordination. Projects fail because information falls into the cracks and/or stakeholders fail to coordinate their efforts. Principle #6. Manage change. Approach may formal or informal. You need mechanisms to manage how changes are requested, assessed, approved and implemented. Principle #7. Assess risk. Lots of things can go wrong as software is being developed, establish contingency plans. Principle #8. Create work products that provide value for others. Create only those work products that provide value for other process activities, actions or tasks. © McGraw-Hill 3  Principles that Guide Practice 1 Principle #1. Divide and conquer. Analysis and design should always emphasize separation of concerns (SoC). Principle #2. Understand the use of abstraction. Abstraction is a simplification of a complex system element used to communication meaning simply. Principle #3. Strive for consistency. A familiar context makes software easier to use. Principle #4. Focus on the transfer of information. Pay special attention to the analysis, design, construction, and testing of interfaces. © McGraw-Hill 4  Principles that Guide Practice 2 Principle #5. Build software that exhibits effective modularity. Provides a mechanism for realizing the philosophy of Separation of concerns. Principle #6. Look for patterns. The goal of patterns is to create a body of literature to help developers resolve recurring problems encountered in software development. Principle #7. Use multiple viewpoints. Represent the problem and solution from different perspectives. Principle #8. Some consumes your work products. Remember that someone will maintain the software. © McGraw-Hill 5  Simplified Process Framework Access the text alternative for slide images. © McGraw-Hill 6  Communications Principles 1 Principle #1. Listen. Try to focus on the speaker’s words, not formulating your response to those words. Principle # 2. Prepare before you communicate. Understand a problem before meeting with others. Principle # 3. Someone should facilitate the activity. Every communication meeting should have a leader to keep the conversation moving in a productive direction. Principle #4. Face-to-face communication is best. Visual representations of information can be helpful. Principle # 5. Take notes and document decisions. Someone should serve as a “recorder” and write down all important points and decisions. © McGraw-Hill 7  Communications Mode Effectiveness Access the text alternative for slide images. © McGraw-Hill 8  Communications Principles 2 Principle # 6. Strive for collaboration. Consensus occurs when collective team knowledge is combined. Principle # 7. Stay focused, modularize your discussion. The more people involved in communication the more likely discussion will bounce between topics. Principle # 8. If something is unclear, draw a picture. Principle # 9. (a) Once you agree to something, move on; (b) If you can’t agree to something, move on; (c) If a feature or function is unclear and cannot be clarified at the moment, move on. Principle # 10. Negotiation is not a contest or a game. It works best when both parties win. © McGraw-Hill 9  Iterative Planning Process Access the text alternative for slide images. © McGraw-Hill 10  Planning Principles 1 Principle #1. Understand the scope of the project. Scope provides the software team with a destination as the roadmap is created. Principle #2. Involve the customer in the planning activity. They define priorities and project constraints. Principle #3. Recognize that planning is iterative. A project plan is likely to change as work begins. Principle #4. Estimate based on what you know. Estimation provides an indication of effort, cost, and task duration, based on team’s current understanding of work. Principle #5. Consider risk as you define the plan. Contingency planning is needed for identified high impact and high probability risks. © McGraw-Hill 11  Planning Principles 2 Principle #7. Adjust granularity as you define the plan. Granularity refers to the level of detail that is introduced as a project plan is developed. Principle #8. Define how you intend to ensure quality. Your plan should identify how the software team intends to ensure quality. Principle #9. Describe how you intend to accommodate change. Even the best planning can be obviated by uncontrolled change. Principle #10. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time. © McGraw-Hill 12  Software Modeling Access the text alternative for slide images. © McGraw-Hill 13  Agile Modeling Principles 1 Principle #1. The primary goal of the software team is to build software not create models. Principle #2. Travel light – don’t create more models than you need. Principle #3. Strive to produce the simplest model that will describe the problem or the software. Principle #4. Build models in a way that makes them amenable to change. Principle #5. Be able to state an explicit purpose for each model that is created. © McGraw-Hill 14  Agile Modeling Principles 2 Principle #6. Adapt the models you create to the system at hand. Principle #7. Try to build useful models, forget abut building perfect models. Principle #8. Don’t become dogmatic about model syntax. Successful communication is key. Principle #9. If your instincts tell you a paper model isn’t working you may have a reason to be concerned. Principle #10. Get feedback as soon as you can. © McGraw-Hill 15  Construction Principles - Coding 1 Preparation Principles: Before you write one line of code, be sure you: Principle 1. Understand the problem to be solved. Principle 2. Understand basic design principles and concepts. Principle 3. Pick a programming language that meets the needs of the software to be built. Principle 4. Select a programming environment that provides tools that will make your work easier. Principle 5. Create a set of unit tests that will be applied once the component you code is completed. © McGraw-Hill 16  Construction Principles - Coding 2 Coding Principles: As you begin writing code, be sure you: Principle 6. Constrain your algorithms by following structured programming practice. Principle 7. Consider the use of pair programming. Principle 8. Select data structures that will meet the needs of the design. Principle 9. Understand the software architecture and create interfaces that are consistent with it. © McGraw-Hill 17  Construction Principles - Coding 3 Validation Principles: After you’ve completed your first coding pass, be sure you: Principle 10. Conduct a code walkthrough when appropriate. Principle 11. Perform unit tests and correct errors you’ve uncovered. Principle 12. Refactor the code to improve its quality. © McGraw-Hill 18  Agile Testing Access the text alternative for slide images. © McGraw-Hill 19  Testing Principles 1 Principle #1. All tests should be traceable to customer requirements. Principle #2. Tests should be planned long before testing begins. 1. Testing is a process of executing a program with intent of finding an error, 2. A good test case is one that has a high probability of finding an as-yet- undiscovered error. 3. A successful test is one that uncovers an as-yet-undiscovered error. Principle #3. The Pareto principle applies to software testing. © McGraw-Hill 20  Testing Principles 2 Principle #4. Testing should begin “in the small” and progress toward testing “in the large.” Principle #5. Exhaustive testing is not possible. Principle #6. Testing effort for each system module commensurate to expected fault density. Principle #7. Static testing can yield high results. Principle #8. Track defects and look for patterns in defects uncovered by testing. Principle #9. Include test cases that demonstrate software is behaving correctly. © McGraw-Hill 21  Software Deployment Actions Access the text alternative for slide images. © McGraw-Hill 22  Deployment Principles 1 Principle #1. Customer expectations for the software must be managed. Principle #2. A complete delivery package should be assembled and tested. Principle #3. A support regime must be established before the software is delivered. Principle #4. Appropriate instructional materials must be provided to end-users. Principle #5. Buggy software should be fixed first, delivered later. © McGraw-Hill 23 Because learning changes everything. ® www.mheducation.com © 2020 McGraw-Hill Education. All rights reserved. Authorized only for instructor use in the classroom. No reproduction or further distribution permitted without the prior written consent of McGraw-Hill Education.  Engenharia de Software Aplicada 6. Requisitos de Qualidade ISO/IEC 25010 Introdução ao modelo de qualidade de software Agenda 1. O que é a ISO/IEC 25010? 2. Principais características de qualidade 3. Subcaracterísticas e sua importância 4. Exemplos práticos de aplicação 5. Conclusão ©Nuno Pina 2024 2  O que é a ISO/IEC 25010? - ISO/IEC 25010 é um - Substitui o antigo modelo - Define um modelo para a - Focado em garantir que o padrão internacional para ISO/IEC 9126. qualidade do produto e a software atenda às avaliar a qualidade de qualidade em uso. necessidades dos usuários software. e partes interessadas. ©Nuno Pina 2024 3 ISO/IEC 25010 ©Nuno Pina 2024 4 Modelos de Qualidade - Qualidade do Produto: Avalia as características intrínsecas do software. - Qualidade em Uso: Avalia a eficácia, eficiência, satisfação, segurança e cobertura contextual durante o uso. ©Nuno Pina 2024 5 Qualidade do Produto - 8 Características Funcionalidade Desempenho e O software faz o que foi Eficiência planejado? Tempo de resposta, uso de Inclui completude funcional, recursos e capacidade. correção e adequação. Compatibilidade Usabilidade Integração e co-existência Facilidade de uso, com outros sistemas. acessibilidade, e ergonomia. ©Nuno Pina 2024 6 Qualidade do Produto - 8 Características (continuação) Confiabilidade Segurança Disponibilidade e Proteção contra resistência a falhas. ameaças, confidencialidade, integridade. Manutenibilidade Portabilidade Facilidade de correção, Adaptabilidade e melhoria e adaptação. facilidade de instalação em diferentes ambientes. ©Nuno Pina 2024 7  - Eficácia: O software ajuda o usuário a atingir seus objetivos com precisão? - Eficiência: Usa recursos mínimos para atingir o máximo de resultados? Subcaracterísticas de Qualidade em - Satisfação: O software é agradável e aceitável para o usuário? Uso - Segurança: Garante proteção contra erros ou falhas no uso? - Cobertura Contextual: Funciona em todos os cenários esperados? ©Nuno Pina 2024 8 Exemplo Prático: E-commerce FUNCIONALIDADE: O DESEMPENHO: CARREGA USABILIDADE: É FÁCIL SEGURANÇA: PROTEGE SITE PERMITE EM MENOS DE 2 NAVEGAR NO CATÁLOGO AS INFORMAÇÕES TRANSAÇÕES SEM SEGUNDOS? DE PRODUTOS? FINANCEIRAS DOS FALHAS? USUÁRIOS? PORTABILIDADE: FUNCIONA IGUALMENTE BEM EM DISPOSITIVOS MÓVEIS E DESKTOPS? ©Nuno Pina 2024 9  Importância para a Engenharia de Software - Conformidade com Padrões: ISO - Satisfação do Cliente: Melhora a - Facilidade de Manutenção: Reduz 25010 garante que o software experiência do usuário e a custos futuros ao melhorar a atende a critérios de qualidade confiabilidade do software. manutenibilidade e a escalabilidade reconhecidos. do sistema. ©Nuno Pina 2024 10  Conclusão - A ISO/IEC 25010 oferece um - Aplicar essas características pode - Um bom software não é apenas modelo robusto para avaliar e evitar falhas graves e melhorar a funcional, mas também seguro, garantir a qualidade de software. eficiência do desenvolvimento. eficiente e adaptável. ©Nuno Pina 2024 11 Análise e Especificação de requisitos © Nuno Pina 2024 Agenda  Requisitos  Requisitos Funcionais  Requisitos Não Funcionais  Exercício. @Nuno Pina 2024  Fase de Requisitos  Após termos analisado os procesos Análise dos processos de negócio de negócio com o fim de melhor o funcionamento da organização.  Requisitos (Levantamento e especificação, Processo de desenvolvimento requisitos funcionais e não funcionais)  Vamos dar inicio ao proceso de desenvolvimento de um sistema que  Análise (Modelo do domínio do sistema) suportará as atividades da organização.  Desenho (Arquitetura do software, modelos de sistema, modelo de dados)  Vamos começar por descobrir e  Implementação (código) especificar os requisitos do sistema a desenvolver.  Validação, integração e instalação  Manutenção @Nuno Pina 2024 Objetivos da fase requisitos  Criar uma especificação de alto nível do que deve ser implementado (what)  Identificar e documentar os Requisitos Funcionais e os Requisitos não funcionais  Compreender e documentar os desejos e necessidades dos stakeholders  Chegar a acordo sobre o sistema a construir  Alcançar um consenso entre os stakeholders sobre os requisitos  Minimizar o risco de entregar um sistema que não atende os desejos das partes interessadas @Nuno Pina 2024 Principais atividades da fase de Requisitos Descobrir os Requisitos Fase de Requisitos Classificar especificar e organizar os requisitos Validar os requisitos @Nuno Pina 2024 O que é um requisito?  re·qui·si·to substantivo masculino  1. Coisa necessária e indispensável.  2. Condição indispensável; exigência. adjectivo  3. Requerido; requisitado. "requisito", in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2013, http://www.priberam.pt/dlpo/requisito [consultado em 21-03-2014]. @Nuno Pina 2024 O que é um requisito?  Condição que se deve satisfazer para alcançar um objetivo  Exigência que deve ser cumprida para atingir um objetivo @Nuno Pina 2024 Descoberta dos Requisitos  Os requisitos vêm do contexto do sistema que estamos a modelar.  O engenheiro de requisitos necessita de extrair todas as informações possíveis dos stakeholders e identificar os requisitos  Envolve pessoal técnico que trabalha com os clientes a fim de investigar o domínio da aplicação, os serviços que o sistema deveria oferecer e as restrições operacionais do sistema @Nuno Pina 2024 Descoberta dos Requisitos - problemas típicos  Pressão do cliente para uma construção rápida do sistema => Requisitos Incompletos @Nuno Pina 2024 Descoberta dos Requisitos - problemas típicos  Problemas de Comunicação “Quando conversar com um colega de trabalho ou um cliente, lembre-se de que a comunicação transcende as palavras.” - Mari Geuer Omissão de Requisitos @Nuno Pina 2024 Descoberta dos Requisitos - problemas típicos  Suposição incorreta que o assunto é evidente “Geralmente as pessoas falham em serem bons ouvintes. Elas simplesmente presumem que sabem o que a outra pessoa esta dizendo ou simplesmente porque elas já ouviram isso antes adotam a ideia de que aquela pessoa é igual a outra “ Ambiguidade de Requisitos @Nuno Pina 2024 Descoberta dos Requisitos - problemas típicos  Toda a gente filtra informação para criar o seu modelo particular do mundo => O mapa não é o território  Noam Chomsky descreve esta filtragem como um processo de três fases:  Supressão ("deletion") – a informação é filtrada  Distorção ("distortion") – a informação é modificada pelos mecanismos relacionados com a criação e a alucinação  Generalização ("generalization") – a criação de regras, crenças e princípios acerca de veracidade ou falsidade @Nuno Pina 2024  Requisitos funcionais  Definem o comportamento que o sistema deve apresentar. O sistema ATM deverá verificar a validade de um cartão inserido.  O sistema ATM deverá validar o PIN inserido pelo cliente.  O sistema ATM não deverá dispensar mais do que 300€ por dia a qualquer cartão. @Nuno Pina 2024 Requisitos não funcionais  Os Requisitos não Funcionais definem as propriedades e as restrições do sistema. Dividem-se em:  Requisitos ambientais – definem os constrangimentos a nível de sofware, hardware e normas a utilizar.  Requisitos de qualidade – definem as propriedades do produto a desenvolver.  Exemplos de requisitos ambientais:  O sistema ATM deverá ser implementado usando a linguagem C++  O sistema ATM deverá comunicar com o banco utilizando encriptação de 256-bits  Exemplos de requisitos de qualidade:  O sistema ATM deverá validar um cartão em três segundos ou menos.  O sistema ATM deverá ser compatível com o sistema Linux e o sistema Windows @Nuno Pina 2024 Tipos de requisitos não-funcionais Requisitos Não Funcionais Qualidade Ambientais Desempenho Disponibilidade Adaptabilidade Usabilidade Hardware Capacidade de Fiabilidade Portabilidade Facilidade de Software Resposta Aprendizagem Capacidade de Eficácia de Normas/ Armazenamento Manutenibilidade Extensibilidade Utilização legislação Capacidade de Integridade Resistência a Processamento Erros Satisfação de Utilização @Nuno Pina 2024 @Patricia Macedo; Nuno Pina 2020 ISO 9126 (norma antiga) ISO/IEC 9126 Software engineering — Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011. @Nuno Pina 2024 ISO 25010 (atual) O modelo de qualidade é: A pedra angular de um sistema de avaliação da qualidade de um produto. Determina quais características de qualidade serão tidas em conta ao avaliar as propriedades de um produto de software. A qualidade de um sistema é o grau em que o sistema satisfaz as necessidades declaradas e implícitas dos seus diversos intervenientes, proporcionando assim valor. Essas necessidades dos intervenientes (funcionalidade, desempenho, segurança, manutenibilidade, etc.) são precisamente o que está representado no modelo de qualidade, que categoriza a qualidade do produto em características e sub-características. @Nuno Pina 2024 ISO 25010 (atual) O modelo de qualidade do produto definido na ISO/IEC 25010 compreende as nove características de qualidade mostradas na figura seguinte: @Nuno Pina 2024 Especificação dos requisitos  Não existe um standard para a escrita dos requisitos.  Especificações em linguagem estruturada  Especificações baseadas em formulários  Especificação baseada em PDL (linguagem parecida com uma linguagem de programação, sendo mais abstrata )  Padrão de requisitos IEEE. @Nuno Pina 2024 Especificação dos requisitos funcionais  Na disciplina de ESA iremos utilizar a seguinte representação O deverá identificador único nome do sistema Keyword função a desempenhar @Nuno Pina 2024 Especificação dos requisitos de qualidade  A especificação dos requisitos qualidade deve ser efetuada de forma a garantir não ambiguidade.  Deve-se indicar qual a métrica que se vai utilizar para validar o requisito. O deve.... Categoria de Requisito de Qualidade: Teste: Escala: especificação da escala de medida Pior caso : valor mínimo para aceitação do sistema @Nuno Pina 2024 Especificação dos requisitos de qualidade  Exemplo O sistema gestClinica deve garantir a persistência dos dados de pelo menos 1000 clientes e 5000 receitas Categoria do Requisito: Capacidade de Armazenamento Teste Registo de 1000 clientes e de 5000 receitas, e teste posterior às funcionalidades do sistema, referente as entidades cliente e receita. Escala: Unidades de Registo Pior caso (valor mínimo para Registo de 1000 clientes e de 5000 receitas aceitação do sistema) @Nuno Pina 2024 Técnicas para a descoberta dos requisitos Uma das etapas da fase de requisitos consiste na descoberta/levantamento dos mesmos. Existem várias técnicas que podem ser utilizadas, tais como:  Entrevistas  Questionários  Workshops  Etnografia @Nuno Pina 2024 Técnicas para a descoberta dos requisitos: Entrevista  Aspectos essenciais a ter em conta durante a entrevista  Não "alucinar" a solução – pode-se ter uma boa ideia do que necessitam os stakeholders, mas durante a entrevista, é necessário afastar essa ideia preconcebida  Fazer questões "context-free" – são questões que não pressupõe nenhum tipo particular de resposta e encorajam o entrevistado a falar acerca do problema ◼ Quem utiliza o sistema – context-free – encoraja a discussão ◼ Você utiliza o sistema – implica uma resposta sim/não e encerra a discussão  Escutar – dar tempo ao entrevistado para falar. Permitir que ele responda à sua maneira.  Não tentar ler o pensamento  Ter paciência @Nuno Pina 2024 Técnicas para a descoberta dos requisitos: Questionários  Os questionários podem ser utilizados como complemento das entrevistas  Não se devem utilizar sem ter realizado primeiro as entrevistas  Caso contrário, como escolher as questões mais corretas? @Nuno Pina 2024 @Patricia Macedo; Nuno Pina 2020 Técnicas para a descoberta dos requisitos - workshops Participantes: promotor, um engenheiro de requisitos, os principais stakeholders e peritos no domínio 1. Explicar que se trata de um verdadeiro brainstorm. 1. Todas as ideias são aceites como boas ideias 2. As ideias são registadas e não debatidas 2. Pedir aos membros das equipas para nomear os seus requisitos para o sistema 1. Escrever cada requisito num post-it 2. Afixar o post-it num quadro ou numa parede 3. Poderá optar por fazer iterações sobre os requisitos identificados e anotar atributos adicionais para cada um deles 4. Depois da reunião, analisar os resultados e convertê-los para requisitos. 5. Fazer circular os resultados para obter comentários @Nuno Pina 2024 Técnicas para a descoberta dos requisitos - Etnografia  O sociólogo gasta um tempo considerável no ambiente de trabalho a observar e a anotar como os participantes envolvidos trabalham  Interações implícitas são reveladas. As pessoas não têm que explicar o seu trabalho  Factores sociais e organizacionais importantes podem ser observados  Os requisitos são derivados levando em consideração a cooperação das atividades de outras pessoas  Estudos etnográficos mostram que a descrição do trabalho é mais rica e complexa do que o sugerido por outros modelos de sistemas. @Nuno Pina 2024 Validação dos Requisitos  Confirmar que os requisitos identificados representam o sistema que o cliente pretende.  Resolver situações de conflitos e inconsistência entre requisitos. @Nuno Pina 2024 Validação dos Requisitos  Validade - o sistema prevê as funções que atendem as necessidades do cliente?  Consistência - há conflitos de requisitos?  Completude - todas as funções requeridas pelo cliente estão incluídas?  Realismo - os requisitos podem ser implementados com o orçamento e tecnologia disponíveis?  Verificabilidade - os requisitos podem ser verificados? @Nuno Pina 2024 Validação dos Requisitos - Técnicas  Revisões de requisitos  Análise manual sistemática dos requisitos.  Prototipagem  Utilização de um modelo executável do sistema.  Geração de casos de teste  Desenvolver testes para verificar os requisitos.  Análise automatizada da consistência  Verificara consistência de uma descrição de requisitos estruturada. @Nuno Pina 2024 Análise e Especificação de requisitos © Nuno Pina 2024  Metodologias de desenvolvimento de SW Nuno Pina Gonçalves [email protected] Processo de desenvolvimento de SW Nuno Pina Gonçalves 2024 2  Visão Geral Modelo em Cascata Modelos de Processo Evolutivos Modelo baseado em Protótipos Modelo em Espiral Modelo Incremental Modelo Unificado Modelos Ágeis Nuno Pina Gonçalves 2024 3  Metodologias Tradicionais Modelo Cascata - Linear/Sequencial Nuno Pina Gonçalves 2024 4  Metodologias Tradicionais Modelo Cascata Alteração dos Requisitos Requisitos Verificar Verificar Especificação Verificar Cada fase é visitada Desenho sequencialmente Verificar No fim de cada fase são verificados os objectivos para Implementação avaliar a progressão Verificar Retrocesso entre fases limitado Integração Cada fase incluí documentação Verificar Desenvolvimento Manutenção Entrega ao cliente Nuno Pina Gonçalves 2024 Conclusão 5  Metodologias Tradicionais Cascata: V-model Modelação Testes Requisitos Aceitação Desenho Testes Arquitectura Sistema Desenho Testes Componentes Integração Geração de Testes Código Unitários Software Executável Nuno Pina Gonçalves 2024 6  Metodologias Tradicionais Modelos evolutivos: Prototipagem Adequado quando o cliente tem uma necessidade mas não consegue especificar os detalhes A construção de protótipos é enquadrada na fase de requisitos A especificação suporta-se no feedback relativo ao protótipo Nuno Pina Gonçalves 2024 7 Metodologias Tradicionais Nuno Pina Gonçalves 2024 8  Metodologias Tradicionais Modelos evolutivos: Espiral planning estimation scheduling risk analysis communication modeling analysis design start deployment construction delivery Refinamento code feedback Maturidade test Nuno Pina Gonçalves 2024 9 Metodologias Tradicionais Modelo incremental Nuno Pina Gonçalves 2024 10  Metodologias Tradicionais Modelo incremental Modelo Incremental Requisitos Verificar Desenvolvimento Especificação Manutenção Verificar Entrega progressiva ao cliente Desenho Divisão do projecto em “builds” Verificar − cada adiciona funcionalidades Por Implementação: Do desenvolvimento das sucessivas Desenho detalhado versões entregáveis do software: Implementação − o 1º incremento é o produto com as Integração funcionalidades de base Teste − novas versões baseadas nas reacções dos utilizadores Capitalização no conhecimento Entrega ao cliente adquirido anteriormente Conclusão Nuno Pina Gonçalves 2024 11  Metodologias Tradicionais Modelo Pontos Fortes Pontos Fracos Cascata - Segurança na passagem entre fases - Rígido - Linear - Risco de insatisfação final - Controlo - Documentação Prototipagem - Permite ao cliente visualizar a ideia - Pode ser complicado definir os relativa ao produto final protótipos - Revisitasse com facilidade fases - Custo e tempo associados anteriores - Assegura que os requisitos do cliente são satisfeitos: Construtivista Espiral - Enfase na análise de riscos - Adequado para projectos maiores - Incorpora actividades dos restantes (e longos!) modelos - … e com equipas experientes - Construtivista - Complexo de usar Incremental - Vai de encontro as necessidades do - Varias versões (controlo!!) cliente progressivamente - Obriga a uma formação continua dos - Ciclos + rápidos com entregas utilizadores operacionais - Se mal usada pode degenerar em - Divide complexidade (Modular/Escalavel) “construir e modificar” Nuno Pina Gonçalves 2024 12 Metodologias Ágeis Metodologias Ágeis Nuno Pina Gonçalves 2024 14 Metodologias Ágeis Nuno Pina Gonçalves 2024 15  Metodologias Ágeis Métodos Preditivos vs Adaptativos Os métodos tradicionais focam-se no planeamento das actividades futuras. A equipa deve ser capaz de reportar exactamente quais as tarefas que estão planeadas para todo o processo de desenvolvimento » Métodos Preditivos Os métodos ágeis focam-se na resposta à mudança. A equipa não consegue reportar exactamente quais as tarefas previstas para daqui a e.g. 6 meses, mas apenas o objectivo da versão a desenvolver e o custo/esforço estimado da mesma » Métodos Adaptativos Nuno Pina Gonçalves 2024 16 Metodologias Ágeis Nuno Pina Gonçalves 2024 17 Metodologias Ágeis Nuno Pina Gonçalves 2024 18 Metodologias Ágeis Providenciam uma estrutura conceptual para reger projetos de engenharia de software, baseada no seguinte conjunto de princípios: Valorização dos indivíduos e das suas interações em detrimento da valorização dos processos e ferramentas Valorização do desenvolvimento de software funcional ao invés de um maior enfase no desenvolvimento de modelos e documentação Valorização da colaboração com clientes ao invés de especificação rígida e altamente formal Valorização da capacidade de adaptação à mudanças em detrimento da capacidade de seguir um plano. Nuno Pina Gonçalves 2024 19  Metodologias Ágeis Considerações Gerais As metodologias ágeis tendem ser adoptadas de forma mais eficiente com equipas de pequena/média – e.g. até 10 elementos Surgem no entanto algumas dificuldades para: – Equipas com membros distribuídos geograficamente – Quando estamos perante culturas organizacionais do tipo: comando e controlo. Nuno Pina Gonçalves 2024 20  Metodologias Ágeis Processo Ágil Contextos em que reconhecidamente os planos têm uma “vida-curta” – resposta efectiva à medida que as alterações ocorrem Efectiva comunicação com todos os intervenientes (stakeholders) É orientado por descrições do cliente sobre o que é pretendido (cenários) – o cliente faz parte da equipa O software é desenvolvido iterativamente com enfâse nas actividades de construção – entrega de múltiplos “incrementos de software” Organização muito própria das equipas de forma a controlar efectivamente o trabalho resumindo … Entrega rápida e incremental de software/componentes operacionais, acomodando a adaptação entre entregas Nuno Pina Gonçalves 2024 21  Metodologias Ágeis Alguns exemplos SCRUM KANBAN XP – extreme Programming DSDM -dynamic systems development method Adaptive Software Development Crystal Clear Feature-Driven Development Pragmatic Programming Nuno Pina Gonçalves 2024 22 Metodologias Ágeis SCRUM Origem de SCRUM O Scrum foi criado por Jeff Sutherland e Ken Schwaber em 1995, e apresentado na conferência Ospsla em Austin no Texas. Neste mesmo ano foi publicado o artigo “SCRUM Software Development Process”. Os autores herdaram o termo “Scrum” do artigo “The New Product Development Game”, publicado por Takeuchi e Nonaka em 1986. Neste artigo eles utilizam o termo “Scrum” obtido do jogo de Rugby, onde fazem uma analogia entre o processo de desenvolvimento de um produto com as táticas de jogo de Rugby, que valorizam o trabalho em equipe. Nuno Pina Gonçalves 2024 23  Metodologias Ágeis Origem de SCRUM Em Rugby, SCRUM é composta por uma equipa de oito elementos que trabalham em conjunto para levar a bola adiante no campo. Uma equipa que trabalha como uma unidade altamente integrada com cada membro desempenhando um papel bem definido e toda a equipa focando-se num único objectivo comum. Nuno Pina Gonçalves 2024 24  Metodologias Ágeis SCRUM - Definições SCRUM define um processo para construir software incrementalmente em contextos complexos, onde os requisitos não são claros ou mudam com muita frequência. SCRUM é um framework ágil de gestão de projetos usado para entregar aos clientes, de forma iterativa, incrementos de produto de alto valor. Nuno Pina Gonçalves 2024 25  Metodologias Ágeis Processo SCRUM Nuno Pina Gonçalves 2024 26  Metodologias Ágeis Processo SCRUM O trabalho a realizar é registado no Product Backlog, que é uma lista de tarefas (incluindo associadas à implementação dos requisitos/funcionalidades) ou de user stories O projeto desenvolve-se numa série de iterações, chamadas incrementos (sprints) No inicio de cada incremento é feita uma Reunião de Planeamento de Incremento (Sprint Planning Meeting) na qual o Dono do Produto (Product Owner) define as prioridades do Product Backlog A Equipa (Scrum Team) selecciona as tarefas que completará durante o próximo Incremento Essas tarefas são então transferidas do Product Backlog para o Sprint Backlog Nuno Pina Gonçalves 2024 27  Metodologias Ágeis Processo SCRUM Durante o incremento, são conduzidas curtas reuniões diárias chamadas de Scrum Diário (Daily Scrum), que ajudam a equipa a sincronizar-se e manter-se coesa e direccionada Ao final de cada incremento a equipa demonstra a funcionalidade concluída, na Sprint Review Meeting Tipicamente: O desenvolvimento é dividido em Sprints de 30 dias Equipas são pequenas O Daily Scrum segue o formato de uma reunião de 15 minutos onde a equipa reporta sobre o que fez e expõe o que será feito no próximo dia e identifica os potenciais factores de impedimento ao progresso Nuno Pina Gonçalves 2024 28 Metodologias Ágeis Nuno Pina Gonçalves 2024 29 Eventos SCRUM Nuno Pina Gonçalves 2024 30 SCRUM Nuno Pina Gonçalves 2024 31 Burndown Chart Nuno Pina Gonçalves 2024 32 Velocity Chart Nuno Pina Gonçalves 2024 33 Outros reports Nuno Pina Gonçalves 2024 34  Metodologias Ágeis eXtreme Programming - XP XP agrega uma colecção de práticas do desenvolvimento de software As práticas recomendadas pela XP não são novas individualmente – A contribuição emerge na conjugação e no ênfase extremo que se coloca na sua utilização Objectiva software de alta qualidade – Redução de bugs – Adaptável, modular e escalável Nuno Pina Gonçalves 2024 35  Metodologias Ágeis XP – Processo Integração contínua dos incrementos – O código escrito é integrado na solução completa (processo progressivo) – A solução completa é compilada (minimiza as falhas por dificuldade de integração dos módulos) – Todos os testes são executados – Mantém uma versão testável Reuniões em pé (stand up meetings: SUM) – discussão do progresso do dia anterior e do plano de actividade para o dia (máximo ½ hora) Enfase no combate ao erro (abugging) – Passo sustentável (tempo de trabalho fixo) Solução central 4 O cansaço causa erros: menos horas; maior intensidade Testes A concentração intensa aumenta a qualidade Passaram – Desenho simples 1 não incluir no código nada que não seja essencial. 3 Integração Correr Testes – Seguir standards de codificação 2 “Releases curtas” Testes – para obter feedback do cliente. Falharam Módulos Novos Nuno Pina Gonçalves 2024 36  Metodologias Ágeis XP – Principais Práticas Spiking – investigar e experimentar tecnologias necessárias à solução – O aprofundar de conhecimentos deve ser transmitido/partilhado Desenvolvimento orientado por testes (TDD) – é a prática de escrever testes unitários antes de escrever o código Escrever – evitar os enviesamentos dos testes realizados à posteriori testes Refactoring – antecipar/evitar esforço em processo de debug – recurso a ferramentas (e.g. NUnit: http://www.NUnit.org) Refactoring – é o processo de alterar/optimizar a estrutura do código (e.g. remoção de código desnecessário) Escrever – atenção aos critérios para encetar o processo de refactoring o código Integração Pair Programming – proporciona uma revisão contínua do código, ajuda a disseminar conhecimento e favorece a comunicação Nuno Pina Gonçalves 2024 37  Metodologias Ágeis Programação em Pares Prevê 2 papéis: o programador e o colega. O programador declara qual a função que pretende programar. Quanto o programador acaba, declara-o. O colega classifica – e.g. dá uma pontuação de 0 a 10 – por cada ponto abaixo de 10 o colega tem de explicar como obter o 10 Trocam de papéis e o processo recomeça Nuno Pina Gonçalves 2024 38  Metodologias Ágeis Programação em Pares Recomendações para o colega: – Assegurar-se que o feedback é positivo – Não fazer comentários pessoais, manter o foco no programa e não no programador Recomendações para o programador: – Não esquecer que os comentários se destinam a melhorar a qualidade do código – Manter uma atitude de gratidão pela ajuda prestada pelo colega Nuno Pina Gonçalves 2024 39 Metodologias Ágeis KANBAN Nuno Pina Gonçalves 2024 40  Metodologias Ágeis KANBAN O Kanban foi criado por criado Taiichi Ohno como o sistema de planeamento de produção da Toyota (TPS). Para comunicar em tempo real os níveis de capacidade, os trabalhadores passavam um cartão, ou “Kanban”, entre as equipas ou aos fornecedores Quando uma caixa de material terminava na linha de produção, um Kanban era passado para o armazém, descrevendo as características e quantidade do material em falta. Nuno Pina Gonçalves 2024 41  Metodologias Ágeis KANBAN O armazém deveria de imediato enviar uma nova caixa cheia de material para a linha de produção e enviar um Kanban ao fornecedor a notificar a necessidade. O fornecedor, por sua vez, responderia de imediato enviando uma caixa desse material para o armazém da fábrica da Toyota. Este mesmo processo ainda está no centro do processo de fabricação “just in time”. No inicio do seculo XXI, o Kanban deixou de estar restrito à industria automóvel para ser aplicado com sucesso a outros sectores complexos, como o IT, desenvolvimento de software e o marketing. O que hoje reconhecemos como o Método Kanban, com todos os seus principais elementos, emergiu com David J. Anderson, o primeiro a aplicar o conceito ao trabalho de IT e desenvolvimento de software. Nuno Pina Gonçalves 2024 42 Metodologias Ágeis KANBAN Nuno Pina Gonçalves 2024 43 Metodologias Ágeis KANBAN Nuno Pina Gonçalves 2024 44 Ferramentas Nuno Pina Gonçalves 2024 45 Ferramentas Nuno Pina Gonçalves 2024 46 Ferramentas Nuno Pina Gonçalves 2024 47 Outras metodologias ágeis (MIX) Nuno Pina Gonçalves 2024 48 Seleção da Metodologia  Metodologias Ágeis Seleção do Modelo de Desenvolvimento Sequencial Iterativa Requisitos Estáveis Instáveis ou pouco entendidos Desenho Familiar e repetível Complexo e desafiante Equipa Conhece o contexto Estranha ao contexto Risco Reduzido Elevado Previsibilidade Importante Negligenciável Alterações Caras Baratas Modelo sequencial linear coloca ênfase no cumprimento do plano de projeto, com entrega do sistema final no prazo previsto Nuno Pina Gonçalves 2024 50 Metodologias Ágeis Modelo Sequencial Nuno Pina Gonçalves 2024 51  Metodologias Ágeis Modelos Iterativos Nuno Pina Gonçalves 2024 52  Metodologias de desenvolvimento de SW Nuno Pina Gonçalves [email protected] Requisitos – Modelação com Use Cases © Nuno Pina– 2024  Agenda 2  O que é modelação com use cases (casos de uso)  Diagrama de use cases  Elementose notações gráficas  Relacionamentos  Como identificar os elementos durante o levantamento de requisitos  Exercícios. © Nuno Pina 2024  Modelação com Use Cases 3  A modelação com use cases é uma abordagem utilizada na engenharia de requisitos  Suporta o processo de levantamento dos requisitos funcionais do sistema  Cria-se um modelo onde são identificadas as funcionalidades que o sistema deverá apresentar para cada um dos seus utilizadores.  Utiliza-se o diagrama de use cases da Unified Modelling Language (UML) para representar o modelo. © Nuno Pina 2024  UML - Diagramas 4 Suportam o processo de analise e especificação de Requisitos Modelam a estrutura (componente estática do sistema). Modelam o comportamento (componente dinâmica do sistema). © Nuno Pina 2024  Modelação com Use Cases 5  A modelação com use cases é muito útil quando: O sistema é dominado por requisitos funcionais  O sistema tem diversos tipos de utilizadores a quem fornece diferentes funcionalidades  O sistema tem muitos interfaces  A modelação com use cases não é adequada para capturar restrições do sistema (requisitos não funcionais). © Nuno Pina 2024  Modelação com Use Cases 6  Elementos a incluir no modelo O quê ou quem utiliza o sistema.  Quais as funções que o sistema deverá oferecer aos seus utilizadores.  Onde se situa a fronteira do sistema. © Nuno Pina 2024  Diagrama de Use Case 7  Ator (O quê ou quem)  Um ator interage diretamente com o sistema  Os atores identificam quem utiliza o sistema  Um ator especifica um papel ("role") desempenhado por uma entidade externa quando interage com o sistema  Um ator pode ser outro sistema