UMC Universidade de Mogi das Cruzes. Notas de Aula. Profa. MSc. Viviane Guimarães Ribeiro

Transcrição

1 UMC Universidade de Mogi das Cruzes Notas de Aula Profa. MSc. Viviane Guimarães Ribeiro 2014

2 Índice APRESENTAÇÃO DA DISCIPLINA... 4 PLANO DE ENSINO... 4 EMENTA... 4 OBJETIVO DA DISCIPLINA... 4 TÓPICOS DO SEMESTRE... 4 METODOLOGIA... 4 FERRAMENTA CASE... 4 AVALIAÇÃO... 4 DATAS IMPORTANTES... 5 BIBLIOGRAFIA BÁSICA... 5 BIBLIOGRAFIA COMPLEMENTAR MODELAGEM DE SISTEMAS DE SOFTWARE A EVOLUÇÃO HISTÓRICA DA MODELAGEM DE SISTEMAS O PARADIGMA DA ORIENTAÇÃO A OBJETOS CLASSES E OBJETOS MENSAGENS O PAPEL DA ABSTRAÇÃO UML DIAGRAMA DE CASO DE USO DIAGRAMA DE CLASSE DIAGRAMA DE OBJETOS DIAGRAMA DE SEQUENCIA DIAGRAMA DE COMUNICAÇÃO/COLABORAÇÃO DIAGRAMA DE MÁQUINA DE ESTADO/TRANSIÇÃO DE ESTADOS DIAGRAMA DE PACOTES DIAGRAMA DE COMPONENTES DIAGRAMA DE IMPLEMENTAÇÃO/IMPLANTAÇÃO DIAGRAMA DE ATIVIDADES DIAGRAMA DE TEMPO/TEMPORIZAÇÃO DIAGRAMA DE ESTRUTURA COMPOSTA DIAGRAMA DE VISÃO GERAL/GERAL DE INTERAÇÃO O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ATIVIDADES TÍPICAS DE UM PROCESSO DE DESENVOLVIMENTO PARTICIPANTES DO PROCESSO MODELOS DE CICLO DE VIDA INTRODUÇÃO À FASE DE ANÁLISE LEVANTAMENTO DE REQUISITOS TÉCNICAS UTILIZADAS APLICAÇÃO PRÁTICA SISTEMA ACADÊMICO Profa. MSc. Viviane Guimarães Ribeiro 2

3 6. MODELAGEM DE CASO DE USO DIAGRAMA DE CASO DE USO - DCU IDENTIFICAÇÃO DOS ELEMENTOS DO DCU CONSTRUÇÃO DO DCU COMPLEXIDADE DOS CASOS DE USO TIPO DE CASOS DE USO DIAGRAMA DE ATIVIDADES ELEMENTOS DE UM DIAGRAMA DE ATIVIDADES RAIAS (SWIMLANES) INTRODUÇÃO AO DIAGRAMA DE CLASSE ESTÁGIOS DO MODELO DE CLASSES DIAGRAMA DE CLASSES Profa. MSc. Viviane Guimarães Ribeiro 3

4 Apresentação da Disciplina Nome da Disciplina: Análise Orientada a Objetos Professora MSc. Viviane Guimarães Ribeiro viviane_umc@yahoo.com.br Ementa Plano de Ensino Processo de desenvolvimento de sistemas com Orientação a Objetos. Especificação de requisitos. Modelagem de sistemas Orientados a Objetos utilizando UML. Objetivo da Disciplina Conhecer as técnicas e saber realizar o levantamento de requisitos de sistemas, identificar os envolvidos e os problemas a resolver, definir o escopo do projeto. Saber modelar os sistemas com diagramas de "use case" e de atividades. Tópicos do Semestre 1) Modelagem de Sistemas de Software 2) Paradigma Orientado a Objetos a. Classes b. Objetos c. Encapsulamento d. Polimorfismo e. Herança 3) Linguagem de Modelagem Unificada (UML) 4) O Processo de Desenvolvimento de Software a. Atividades Típicas de um Processo de Desenvolvimento b. Participantes do Processo c. Modelos de Ciclo de Vida 5) Levantamento e Documentação de Requisitos 6) Modelagem de Casos de Uso 7) Modelagem de Atividades Metodologia Aulas expositivas exercícios de fixação. Ferramenta Case Astah disponível em Avaliação M1 = P1 (70%) + AP (30%) ND = P2 (70%) + AP (30%) M2 = ND (70%) + PI (30%) Média Semestral = (M1 + M2 * 2) / 3 Onde: P1 e P2 são provas individuais, escritas e sem consulta, previamente agendadas. Profa. MSc. Viviane Guimarães Ribeiro 4

5 AP são as atividades práticas realizadas em sala (sem a necessidade de agendamento prévio) ou em casa. PI prova interdisciplinar agendada pela gestão do curso. Datas Importantes P1 P2 Recuperação OBS1: Não será aplicada prova substitutiva. OBS2: A disciplina tem caráter acumulativo, portanto em todas as provas será cobrado todo o conteúdo estudado até o momento no semestre. Bibliografia Básica PAULA FILHO, Wilson de Pádua; Engenharia de Software: Fundamentos, Métodos e Padrões, LTC, Rio de Janeiro, BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar; UML Guia do Usuário, Editora Campus, Rio de Janeiro, BEZERRA, Eduardo; Princípios de Análise e Projeto de Sistemas com UML, Editora Campus, Rio de Janeiro, Bibliografia Complementar MARTINS, José C. C.; Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML, Brasport, Rio de Janeiro, JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James; The Unified Software Development Process, Addison-Wesley, Massachusetts, PRESSMAN, Roger S.; Software Engineering: a practitioner s approach, Pearson Makron Books, São Paulo, LIMA, Adilson da Silva; UML 2.3: do requisito à solução, Érica, São Paulo, KRUCHTEN, Philippe; The rational unified process An introduction, Massachusetts, AddisonWesley, FURGERI, Sérgio; Modelagem de Sistemas Orientados a Objetos: Ensino Didático, Érica, São Paulo, Profa. MSc. Viviane Guimarães Ribeiro 5

6 1. Modelagem de Sistemas de Software Em consequência do crescimento da importância da informação, surgiu a necessidade de gerenciar informações de uma forma adequada e eficiente e, dessa necessidade, surgiram os denominados Sistemas de Informação. Um sistema de informação é uma combinação de pessoas, dados, processos, interfaces, redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização empresarial com relação às informações que nela fluem. Considerando o caráter estratégico da informação nos dias de hoje, pode-se dizer também que os sistemas de informação têm o objetivo de prover vantagens para uma organização do pronto de vista competitivo. O objetivo principal e final da construção de um sistema de informação é a adição de valor à empresa ou organização na qual esse sistema será utilizado. O termo adição de valor implica que a produtividade nos processos da empresa na qual o sistema de informação será utilizado deve aumentar de modo significativo, de tal forma a compensar os recursos utilizados na construção do sistema. Um sistema de software (componente de um sistema de informação) corresponde aos módulos funcionais computadorizados que interagem entre si para proporcionar ao(s) usuário(s) do sistema a automação de diversas tarefas. Uma característica intrínseca de sistemas de software é a complexidade de seu desenvolvimento, que aumenta a medida que cresce o tamanho do sistema. Na construção de sistemas de software, assim como na construção civil, também há uma gradação de complexidade. Para a construção de sistemas de software mais complexos, também é necessário um planejamento inicial. O equivalente ao projeto das plantas da engenharia civil também deve ser realizado. Essa necessidade leva ao conceito de modelo, tão importante no desenvolvimento de sistemas. De uma perspectiva mais ampla, um modelo pode ser visto como uma representação idealizada de um sistema de ser construído. São vários os motivos para se utilizar modelos na construção de sistemas. Segue-se uma lista destas razões. 1. Gerenciamento da complexidade o ser humano possui limitações em lidar com a complexidade. Para um mesmo sistema podem ser feitos diversos modelos, cada qual descrevendo uma perspectiva do sistema a ser construído; Profa. MSc. Viviane Guimarães Ribeiro 6

7 2. Comunicação entre pessoas envolvidas o desenvolvimento de um sistema envolve a execução de uma quantidade significativa de atividades. Essas atividades se traduzem em informações sobre o sistema em desenvolvimento. Grande parte dessas informações corresponde aos modelos criados para representar o sistema. Neste sentido, os modelos servem também para promover a difusão de informações relativas ao sistema entre os indivíduos envolvidos em sua construção; 3. Redução nos custos do desenvolvimento no desenvolvimento de sistemas, seres humanos estão invariavelmente sujeitos a cometerem erros, que podem ser tanto individuais quanto de comunicação entre os membros da equipe. Certamente, a correção destes erros é menos custosa quando detectada e realizada ainda no(s) modelo(s) do sistema; 4. Previsão do comportamento futuro do sistema os modelos servem como laboratório, em que diferentes soluções para um problema relacionado à construção do sistema podem ser experimentadas; Outra questão importante é sobre como são os modelos de sistemas de software. Modelos de sistemas de software não são muito diferentes dos modelos de sistema da construção civil. No contexto do desenvolvimento de software, esses modelos correspondem a desenhos gráficos que seguem algum padrão lógico. Tais desenhos são chamados de diagramas. Graças aos desenhos gráficos que modelam o sistema, os desenvolvedores têm uma representação concisa do sistema. No entanto, modelos de sistema de software também são compostos por informações textuais. Embora um diagrama consiga expressar diversas informações de forma gráfica, em diversos momentos há a necessidade de adicionar informações na forma de texto, com o objetivo de explicar ou definir certas partes desse diagrama. Dá se o nome de documentação do sistema ao conjunto de modelo de uma das perspectivas de um sistema, juntamente com a informação textual associada A Evolução Histórica da Modelagem de Sistemas Década de 1950/60 Os sistemas eram significativamente mais simples e, consequentemente, as técnicas de modelagem também eram mais simples: era a época dos fluxogramas e diagramas de módulos; Década de 1970 Houve uma grande expansão do mercado computacional. Sistemas mais complexos começaram a surgir. Por conseguinte, modelos mais robustos foram propostos. Neste período, surge a programação estruturada, baseada nos trabalhos de David Parnas. No final dessa década, surge também a análise e o projeto estruturado, consolidados pelos trabalhos de Tom DeMarco, Larry Constantine e Edward Yourdon; Década de 1980 Surge a necessidade por interfaces homem-máquina mais sofisticadas, o que originou a produção de sistemas de software mais complexos. Em 1989, Edward Yourdon lança o clássico Análise Estruturada Moderna, livro que se tornou uma referência no assunto; Década de 1990 Esse é o período que surge um novo paradigma de modelagem, a Análise Orientada a Objetos, como resposta a dificuldades encontradas na aplicação da Análise Estruturada a certos domínios de aplicação. Grandes colaboradores no desenvolvimento do paradigma OO são: Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivar Jacobson. Fim da década de 1990 o paradigma OO atinge sua maturidade. Os conceitos de padrões de projeto, frameworks, componentes e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem Unificada (UML). Em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio internacional de empresas que define e gerencia padrões na área de Orientação a Objetos. Profa. MSc. Viviane Guimarães Ribeiro 7

8 2. O Paradigma da Orientação a Objetos Um paradigma é uma forma de abordar um problema. No contexto da modelagem de um sistema de software, um paradigma tem a ver com a forma pela qual este sistema é entendido e construído. A primeira abordagem utilizada para a modelagem de sistemas de software foi o paradigma estruturado. O paradigma OO surgiu no fim dos anos 60. Alan Kay, um dos pais desse paradigma, formulou a chamada analogia biológica. Nessa analogia ele imaginou como seria um sistema de software que funcionasse como um ser vivo. Neste sistema cada célula interagia com outras células através do envio de mensagens para realizar um objetivo comum. Além disso, cada célula se comportaria como uma unidade autônoma. De uma forma geral, Kay pensou em como construir um sistema de software a partir de agentes autônomos que interagem entre si. Ele, então, estabeleceu os seguintes princípios da orientação a objetos: 1. Qualquer coisa é um objeto; 2. Objetos realizam tarefas por meio da requisição de serviços a outros objetos; 3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares; 4. A classe é um repositório para comportamento associado ao objeto; 5. Classes são organizadas em hierarquias. Exemplo: Nome, end, sabor sabor João José Maria pizza, end pizza pizza Zuca Objetivo atingido através da colaboração de diversos agentes denominados Objetos. Objetos: João, José, Maria e Zuca. Cada um faz uma atividade especifica e juntos realizam o objetivo. Zuca se comporta exatamente como qualquer outro entregador. Dizemos que Zuca é um objeto da classe entregador. Pode-se concluir que a Orientação a objetos como técnica para modelagem de sistemas, diminui a diferença semântica entre a realidade sendo modelada e os modelos construídos Classes e Objetos O mundo real é formado por coisas. Como exemplos dessas coisas, pode-se citar um cliente, uma loja, uma venda, um pedido de compra, um fornecedor, etc. Na terminologia da orientação a objetos, essas coisas do mundo real são denominadas objetos. Profa. MSc. Viviane Guimarães Ribeiro 8

9 Seres humanos costumam agrupar objetos, provavelmente para tentar gerenciar a complexidade de entender as coisas do mundo real. Uma classe é uma descrição abstrata dos atributos e serviços comuns a um grupo de objetos. Sendo assim, pode-se entender uma classe como sendo um molde a partir do qual objetos são construídos. Ainda sobre terminologia, diz-se que um objeto é uma instância de uma classe. Instância pode ser vista como a criação de um exemplo para uma classe qualquer. Exemplos: Cavalo (classe) diferenças que possam haver entre os exemplares (objetos) da ideia cavalo. Receita de bolo (classe) bolo (objeto) - podemos fazer vários bolos de chocolate a partir da mesma receita Profa. MSc. Viviane Guimarães Ribeiro 9

10 Nome da classe Operações (funções) +nome -nascimento -documento Pessoa +definirnome () +obternome () +definirnascimento () +obternascimento () +definirdocumento () +obterdocumento () Atributos (dados) 2.2. Mensagens Dá-se o nome de operação a alguma ação que um objeto sabe realizar quando solicitado. De uma forma geral, um objeto possui diversas operações. Objetos não executam suas operações aleatoriamente. Para que uma operação em um objeto seja executada, deve haver um estímulo enviado a esse objeto. Seja qual for a origem do estímulo, quando ele ocorre, diz-se que o objeto em questão está recebendo uma mensagem requisitando que ele realize alguma operação O Papel da Abstração Uma abstração é qualquer modelo que inclui os aspectos relevantes de alguma coisa, ao mesmo tempo em que ignora os menos importantes. Note que uma abstração de algo é dependente da perspectiva (contexto) sobre a qual uma coisa é analisada e de quem as observa. Exemplo: Carro para uma transportadora de cargas; Carro para uma fábrica de automóveis; Carro para um colecionador; Carro para uma empresa de kart; Carro para um mecânico. Profa. MSc. Viviane Guimarães Ribeiro 10

11 A orientação a objetos faz uso intenso de abstrações. Os princípios da orientação a objetos podem ser vistos como aplicações da abstração. Encapsulamento Objetos possuem comportamento. O termo comportamento diz respeito a que operações são realizadas por um objeto e também de que modo estas operações são executas. De acordo com o encapsulamento, objetos devem esconder a sua complexidade. Esse princípio aumenta a qualidade do sistema de software orientado a objetos em termos de: legibilidade, clareza e reuso. O encapsulamento é uma forma de restringir o acesso ao comportamento interno de um objeto. Um objeto que precise da colaboração de outro para realizar alguma tarefa simplesmente envia uma mensagem a este último. O método (maneira de fazer) que o objeto requisitado usa para realiza a tarefa não é conhecido dos objetos requisitantes. Profa. MSc. Viviane Guimarães Ribeiro 11

12 Na terminologia da orientação a objetos, diz-se que um objeto possui uma interface. A interface de um objeto é o que ele conhece e o que ele sabe fazer, sem descrever como o objeto conhece ou faz. A interface de um objeto define os serviços que ele pode realizar e consequentemente as mensagens que ele recebe. Uma interface pode ter várias formas de implementação. Mas, pelo princípio do encapsulamento, a implementação utilizada por um objeto receptor de uma mensagem não importa para o objeto remetente da mesma. Polimorfismo O polimorfismo indica a capacidade de abstrair várias implementações diferentes em uma única interface. Exemplo: um mesmo controle remoto sendo utilizado para controlar mais de um aparelho (aplicação do princípio do polimorfismo na vida real). No contexto da orientação a objetos, o polimorfismo diz respeito à capacidade de duas ou mais classes de objetos responderem à mesma mensagem, cada qual de seu próprio modo. O polimorfismo é um mecanismo por meio do qual selecionamos as funcionalidades utilizadas de forma dinâmica por um programa no decorrer de sua execução. Por exemplo: podemos assumir que uma bola de futebol e uma camisa da seleção brasileira são artigos esportivos, mais que o cálculo deles em uma venda é calculado de formas diferentes. Profa. MSc. Viviane Guimarães Ribeiro 12

13 Profa. MSc. Viviane Guimarães Ribeiro 13

14 Generalização/Herança Na generalização, classes semelhantes são agrupadas em uma hierarquia. Cada nível dessa hierarquia pode ser visto como um nível de abstração. Cada classe em um nível da hierarquia herda as características e o comportamento das classes às quais está associada nos níveis acima dela. Além disso, essa classe pode definir características e comportamento particulares. Dessa forma, uma classe pode ser criada a partir do reuso da definição de classes preexistentes. Vamos analisar a relação entre animais, mamíferos e cachorros. Os animais, sob uma descrição abstrata, apresentam atributos, tais como tamanho, inteligência e estrutura óssea. Apresentam também aspectos comportamentais como mover-se, dormir, comer, respirar, etc. Esses atributos e aspectos comportamentais definem a classe dos animais. Analisando os mamíferos, que são filhos da classe animais, veremos atributos detalhados e específicos a ele, como por exemplo, tipo de dente, pelos e glândulas mamárias. Assim, podemos afirmar que os mamíferos são classificados como uma classe derivada dos animais, que por sua vez, são uma classe base dos mamíferos. Pela chamada hierárquica de classes, a classe derivada mamíferos recebe todos os atributos de animais, partindo do princípio que uma classe derivada recebe por herança todos os atributos de seus ancestrais. Profa. MSc. Viviane Guimarães Ribeiro 14

15 Composição É natural para os seres humanos pensarem em coisas do mundo real como objetos compostos de outros objetos. Por exemplo, um livro é composto de páginas; páginas possuem parágrafos; parágrafos possuem frases, e assim por diante. De uma forma geral, objetos podem ser compostos de outros objetos; esse é o princípio da composição. A composição nos permite criar objetos a partir da reunião de outros objetos. Profa. MSc. Viviane Guimarães Ribeiro 15

16 3. UML A UML é uma linguagem visual para modelar sistemas orientados a objetos, constituída de elementos gráficos (visuais) utilizados na modelagem que permitem representar os conceitos do paradigma Orientado a Objetos e assim construir diagramas que representem diferentes perspectivas de um sistema. Os três principais autores da UML são: Grady Booch, James Rumbaugh e Ivar Jacobson. Cada elemento gráfico possui uma sintaxe e uma semântica que define como deve ser desenhado e seu respectivo significado. Um processo de desenvolvimento que utilize a UML como linguagem de modelagem envolve a criação de diversos documentos. Estes documentos, denominados artefatos de software, podem ser textuais ou gráficos. Os artefatos gráficos produzidos de um sistema OO são definidos através dos diagramas da UML. Profa. MSc. Viviane Guimarães Ribeiro 16

17 3.1. Diagrama de Caso de Uso É um dos mais importantes diagramas da UML e apresenta o sistema sob o ponto de vista dos usuários, ou seja, apenas uma visão externa das funcionalidades existentes no sistema. De maneira bastante simplificada, pense em um caso de uso como uma opção de um menu dentro de um sistema de software. Em outras palavras, esse diagrama mostra o que cada tipo de usuário faz dentro do sistema. Cada funcionalidade é representada por uma elipse contendo um texto. Profa. MSc. Viviane Guimarães Ribeiro 17

18 3.2. Diagrama de Classe O Diagrama de Classes apresenta a estrutura das classes usadas para fabricar o sistema. Trata-se das estruturas internas utilizadas para compor o software. Pense em uma classe como a estrutura básica fundamental a partir da qual um sistema é criado Diagrama de Objetos Ele é basicamente similar ao diagrama de classes e demonstra as ligações existentes entre objetos, em vez de mostrar ligações entre classes. Enquanto o diagrama de classes apresenta apenas a estrutura estática dos atributos, o diagrama de objetos traz o estado atual do objeto, isto é, adiciona conteúdo aos atributos. Assim como um objeto é gerado (instanciado) a partir de uma classe, um diagrama de objetos também é gerado a partir de um diagrama de classes. Profa. MSc. Viviane Guimarães Ribeiro 18

19 3.4. Diagrama de Sequencia Como o nome sugere, este diagrama representa a sequencia com que os objetos se comunicam para realizar uma determinada tarefa. Ele é importante para que o desenvolvedor entenda a responsabilidade de cada elemento (classe ou objeto) presente na execução de algum processo Diagrama de Comunicação/Colaboração O diagrama de comunicação, chamado nas primeiras versões da UML de diagrama de colaboração, é bastante similar ao diagrama de sequencia, isto é, tem o objetivo de demonstrar a comunicação existente entre os elementos, no entanto a ordem na execução das mensagens não é importante. O importante é demonstrar que os objetos colaboram entre si na execução de uma tarefa. Profa. MSc. Viviane Guimarães Ribeiro 19

20 3.6. Diagrama de Máquina de Estado/Transição de Estados O diagrama da máquina de estados descreve o comportamento de um objeto de uma única casse e permite acompanhar os diferentes estados, os quais esse objeto assume durante sua execução, isto é, em seu ciclo de vida. Um pedido de compra, por exemplo, pode assumir diferentes estados, como: aberto, pendente, cancelado, encerrado, etc. Ao reconhecer os diferentes estados, torna-se possível prever quais operações serão necessárias para uma determinada classe. Profa. MSc. Viviane Guimarães Ribeiro 20

21 3.7. Diagrama de Pacotes O diagrama de pacotes tem o objetivo de demonstrar como os arquivos de um sistema (classes, imagens, sons, etc.) estão organizados em pastas (pacotes). Os pacotes permitem armazenar e separar elementos em grupos para melhor organização dos arquivos, dando apoio para a divisão do sistema em subsistemas (divisões de um sistema). O diagrama de pacotes permite também demonstrar as dependências existentes entre as diferentes partes de um sistema. Profa. MSc. Viviane Guimarães Ribeiro 21

22 3.8. Diagrama de Componentes O diagrama de componentes tem o objetivo de representar as diferentes partes (módulos) que compõem um sistema. Um componente pode ser elementar (como uma classe) ou algo mais complexo (como uma parte de um sistema, um módulo). O diagrama de componentes traz uma visão mais macro do sistema, como se fosse uma visão aérea de todas as partes principais Diagrama de Implementação/Implantação O diagrama de implantação tem o objetivo de fornecer uma visão dos componentes físicos necessários para a implantação do sistema, isto é, ele demonstra quais são os computadores, redes, protocolos e outros componentes de hardware necessários para que o sistema desenvolvido funcione. O uso do diagrama de implantação se justifica quando existem diversos elementos físicos necessários à implantação do sistema, pois se o sistema roda em apenas uma máquina, não será necessário desenhar esse diagrama. Profa. MSc. Viviane Guimarães Ribeiro 22

23 3.10. Diagrama de Atividades O diagrama de atividades fornece uma visão interna de alguma funcionalidade do sistema. Apresenta o conjunto de etapas computacionais necessárias para que uma determinada tarefa seja realizada. Profa. MSc. Viviane Guimarães Ribeiro 23

24 3.11. Diagrama de Tempo/Temporização O diagrama de tempo representa o comportamento dos objetos e sua interação em uma escala de tempo, focalizando as condições que mudam no decorrer desse período. Por descrever a mudança de estado de um objeto, esse diagrama se assemelha ao diagrama de máquina de estado e suas relações com o tempo, o diagrama de tempo também possui relação com o diagrama de sequencia. Portanto, esse diagrama é uma mistura de diagrama de sequencia e de estado. Por sua natureza, o diagrama de tempo é mais indicado para aplicações em tempo real Diagrama de Estrutura Composta O diagrama de estrutura composta tem o objetivo de detalhar a estrutura interna de diversos elementos, tais como classes, componentes e classificadores (uma classe que implementa uma interface). Esse diagrama pode ser encarado como sendo uma lupa ou um microscópio, pois com ele você pode visualizar detalhes de construção, relacionamentos internos e os diversos itens envolvidos na estrutura de um elemento. É usado também para modelar colaborações, isto é, busca representar elementos que colaboram entre si para desempenhar uma tarefa. O diagrama de estrutura composta pode ser usado para representar três tipos de visão diferentes: a visão da estrutura interna, a visão das portas de comunicação e a visão das colaborações entre os elementos. Profa. MSc. Viviane Guimarães Ribeiro 24

25 3.13. Diagrama de Visão Geral/Geral de Interação Como o nome sugere, esse diagrama fornece uma visão geral da interação de algum processo. Graficamente é semelhante ao diagrama de atividades, porém utiliza-se de quadros em vez de nós de ação. Cada quadro representa uma interação e pode conter qualquer diagrama de interação dentro dele (sequência, comunicação e tempo). Um quadro pode também conter apenas uma referência para um diagrama de interação sem apresentar seu detalhamento. Profa. MSc. Viviane Guimarães Ribeiro 25

26 4. O processo de Desenvolvimento de Software O desenvolvimento de software é uma atividade complexa. Para dar uma ideia desta complexidade, são listados a seguir alguns dados levantados no Chaos Report, um estudo clássico feito pela Standish Group sobre projetos de desenvolvimento (1994): Porcentagem de projetos que termina dentro do prazo estipulado: 10%; Porcentagem de projetos que são descontinuados antes de chegarem ao fim: 25%; Porcentagem de projetos acima do custo esperado: 60%; Atraso médio nos projetos: um ano. Tentativas de lidar com a complexidade e de minimizar os problemas envolvidos no desenvolvimento de software envolvem a definição de processos de desenvolvimento de software (PDS). Um PDS compreende todas as atividades necessárias para definir, desenvolver, testar e manter um produto de software. Alguns objetivos de um processo de desenvolvimento são: Definir quais as atividades a serem executadas ao longo do projeto; Definir quando, como e por quem tais atividades serão executadas; Prover pontos de controle para verificar o andamento do desenvolvimento; Padronizar a forma de desenvolver software em uma organização. Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento Exemplos de bons processos e metodologias para desenvolvimento de software. RUP - Rational Unified Process. Metodologias Ágeis: o XP - extreme Programming; o Scrum Atividades Típicas de um Processo de Desenvolvimento Um processo de desenvolvimento classifica em atividades as tarefas realizadas durante a construção de um sistema de software. Há vários processos de desenvolvimento propostos. Por outro lado, é um consenso na comunidade de desenvolvimento de software o fato de que não existe o melhor processo de desenvolvimento, aquele que melhor se aplica a todas as situações de desenvolvimento. Cada processo tem suas particularidades em relação ao modo de arranjar e encadear as atividades de desenvolvimento. Entretanto, podem-se distinguir atividades que, com uma ou outra modificação, são comuns à maioria dos processos existentes. São elas: Levantamento de requisitos corresponde a etapa de compreensão do problema aplicada ao desenvolvimento de software (trabalho conjunto entre desenvolvedores/analistas e cliente foco: aspectos lógicos e independentes de implementação); Análise é esta a etapa em que o analista realiza um estudo detalhado dos requisitos levantados na atividade anterior. A partir deste estudo, são construídos os modelos para representar o sistema a ser construído (foco: aspectos lógicos e independentes de implementação); Projeto (Desenho) determina-se como o sistema funcionará para atender aos requisitos, de acordo com os recursos tecnológicos existentes foco: aspectos físicos e dependentes de implementação; Implementação - fase de codificação do sistema utilizando linguagens de programação; Profa. MSc. Viviane Guimarães Ribeiro 26

27 Testes diversas atividades de testes são realizadas para verificação do sistema construído, levando-se em conta a especificação feita anteriormente; Implantação o sistema é empacotado, distribuído e instalado no ambiente do usuário Participantes do Processo Gerentes de Projeto profissional responsável pela coordenação das atividades necessárias à construção do sistema; Analistas profissional que deve entender os problemas do domínio do negócio para que possa definir os requisitos do sistema a ser desenvolvido; Projetistas profissional cujas funções são: avaliar as alternativas de solução do problema resultante da análise e gerar a especificação de uma solução computacional detalhada (Projetista de interface, de redes, de banco de dados); Arquitetos de Software profissional encontrado em grandes equipes, é ele quem toma decisões sobre quais são os subsistemas que compõem o sistema como um todo e quais são as interfaces entre esses subsistemas; Programadores profissional responsável pela implementação dos sistemas; Especialistas de Domínio indivíduo que possui conhecimento acerca da área ou do negócio em que o sistema em desenvolvimento será inserido Cliente; Avaliadores de Qualidade profissional que assegura a adequação do processo de desenvolvimento e do produto de software sendo desenvolvido aos padrões de qualidade estabelecidos pela organização Modelos de Ciclo de Vida Um ciclo de vida corresponde a um encadeamento específico das fases para construção de um sistema. Dois modelos mais importantes: Modelo em cascata; Modelo iterativo e incremental. Profa. MSc. Viviane Guimarães Ribeiro 27

28 Modelo em Cascata Esse modelo apresenta uma tendência para a progressão sequencial entre uma fase e a seguinte. Problemas: Projetos reais raramente seguem um fluxo sequencial; Assume que é possível declara detalhadamente todos os requisitos antes do início das demais fases do desenvolvimento; Existe a propagação de erros pelas fases do processo; Uma versão de produção do sistema não estará ponta até que o ciclo de projeto de desenvolvimento chegue ao final. Modelo em Iterativo e Incremental Iterativo o sistema de software é desenvolvido em vários passos similares. Incremental em cada passo, o sistema é estendido com mais funcionalidades. Divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Cada ciclo considera um subconjunto de requisitos. Esta característica contrasta com a abordagem clássica, na qual as fases são realizadas uma única vez. Profa. MSc. Viviane Guimarães Ribeiro 28

29 Vantagens: Incentiva a participação do usuário; Os riscos do desenvolvimento podem ser mais bem gerenciados; Desvantagem: Mais difícil de gerenciar. Profa. MSc. Viviane Guimarães Ribeiro 29

30 5. Introdução à fase de análise Para formar um bom entendimento do sistema que se deseja desenvolver, algumas perguntas e informações são importantes: Qual é o problema (e o negócio)? Para quem é o sistema? Como o sistema será útil para os interessados? 5.1. Levantamento de requisitos Objetivo: Compreender o que são requisitos de software, saber identificar requisitos em um domínio de negócio e classificá-los como funcionais e não funcionais. A atividade de levantamento de requisitos corresponde à etapa de compreensão do problema aplicada ao desenvolvimento de software. O objetivo principal é que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido. Os desenvolvedores, juntamente com os clientes, tentam levantar e definir as necessidades dos futuros usuários do sistema. Essas necessidades são denominadas de requisitos. Um requisito é uma condição ou capacidade que deve ser alcançada ou possuída por um sistema. Normalmente estes requisitos são identificados a partir do domínio do negócio, que é a área específica na qual um determinado sistema de software será desenvolvido. O domínio do negócio (também chamado de domínio do problema) corresponde à parte do mundo real que é relevante ao desenvolvimento de um sistema, no sentido de que algumas informações e processos desse negócio precisam ser incluídos no sistema. O produto do levantamento de requisitos é o documento de requisitos, que declara os diversos tipos de requisitos do sistema. Os requisitos podem ser classificados como funcionais ou não funcionais. Profa. MSc. Viviane Guimarães Ribeiro 30

31 Requisitos Funcionais São requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar Exemplo: 1. Requisitos em um sistema bancário Solicitar saldo Solicitar depósito Realizar transferência 2. Requisitos em um sistema de hotel fazenda Cadastrar cliente Controlar empréstimos Calcular despesas Sintaxe: Verbo + Objeto Requisitos Não-Funcionais São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter. Em vez de informar o que o sistema fará, os requisitos não-funcionais colocam restrições no sistema. Exemplo: Confiabilidade: medidas quantitativas sobre tempo médio de falhas ou recuperação de falhas. Desempenho: definem tempo de respostas esperados para as funcionalidades. Portabilidade: restrições sobre as plataformas de hardware e software. Segurança: limitações sobre segurança em relação a acessos não autorizados; Usabilidade: facilidade de uso e a necessidade ou não de treinamento dos usuários; Manutenibilidade: define o quanto o software é fácil de ser alterado e deve ser perseguido no processo de codificação de um sistema; Precisão: é um atributo que determina o quanto um software é preciso; Escalabilidade: se refere a possibilidade de aumentar a carga de uso do sistema sem que isso prejudique o seu desempenho; Garantia de suporte: é um atributo que estabelece o nível de comprometimento da empresa desenvolvedora após a venda do sistema; Interoperabilidade: é um atributo que determina se o software pode operar facilmente com outros sistemas na execução de alguma tarefa em conjunto; Internacionalização: o sistema deve ser construído de maneira a facilitar a rápida mudança de língua Técnicas utilizadas Usuários chave Entrevistas o Aplicada a um número reduzido de pessoas; o Permite o diálogo interativo; o Permite visualizar as reações do entrevistado; o Possibilita grande flexibilidade na estrutura original da entrevista. Questionários o Aplicado a um número reduzido de pessoas; o Necessita ser bem estruturado e dirigido para o problema que se quer analisar; o Permite pouca flexibilidade na sua estrutura; o Permite manusear grande número de informações. Workshop o Aplicado a um número reduzido de pessoas; Profa. MSc. Viviane Guimarães Ribeiro 31

32 o Permite interação e discussão aberta; o Produz resultados imediatos e evolução na forma de interpretar e tratar os processos. Observação o É a verificação no local de trabalho, com pequenas interferências do analista; o É aplicado para complementar o levantamento de informações sobre o processo, para garantir o entendimento da situação analisada, ou quando o assunto for muito complexo ou específico. Reuniões Profissionais experientes na área do negócio Analistas e desenvolvedores com experiência técnica Sistemas similares Aplicação Prática Sistema Acadêmico Requisitos Funcionais ID Nome Descrição RF01 Consultar notas O sistema deve permitir que alunos visualizem as notas obtidas por semestre letivo. RF02 Lançar notas O sistema deve permitir o lançamento das notas das disciplinas lecionadas em um semestre letivo e controlar os prazos e atrasos neste lançamento. RF03 Cadastrar disciplina O sistema deve manter informações cadastrais sobre disciplinas no currículo escolar. RF04 Abrir turmas O sistema deve permitir a abertura de turmas para uma disciplina, assim como a definição de sala e laboratórios a serem utilizadas e dos horários e dias da semana em que haverá aulas de tal turma. RF05 Inscrever em disciplina O sistema deve permitir que os alunos realizem a inscrição em disciplinas de um semestre letivo. RF06 Controlar inscrições O sistema deve permitir o controle do andamento das inscrições em disciplinas feitas pelo aluno. RF07 Obter dos dados dos professores O sistema deve se comunicar com o Sistema de Recursos Humanos para obter dados cadastrais sobre os professores. RF08 Informar inscrições O sistema deve se comunicar com o Sistema de Faturamento para informar as inscrições realizadas pelos alunos. RF09 Manter cadastro de alunos O sistema deve permitir o cadastro, a consulta, a alteração e a exclusão de informações referentes a cada aluno. RF10 Manter histórico escolar O sistema deve permitir o cadastro, a consulta, a alteração e a exclusão de informações referentes ao histórico escolar de cada aluno. Profa. MSc. Viviane Guimarães Ribeiro 32

33 Requisito Não funcionais ID Nome Descrição RNF01 Interface web O sistema deve operar via interface Web. RNF02 Sistema operacional O uso da plataforma Windows será priorizada pelo sistema. RNF03 Acesso usuário Controle de acesso dos professores e alunos ao sistema através de usuário, senha e permissão de uso para cada funcionalidade deverá ser oferecido pelo sistema. RNF04 Backup dos dados O sistema deverá executar backup dos dados a cada semana. RNF05 Calendário Haverá um calendário disponível para que o aluno possa saber dos eventos internos da instituição, férias, feriados. RNF06 Tempo de resposta O tempo de resposta de entrada de dados, consulta e quaisquer outros tipos será de 2s. RNF07 Ajuda Todos os controles de interface devem ter um campo de ajuda associado Profa. MSc. Viviane Guimarães Ribeiro 33

34 6. Modelagem de Caso de Uso O Modelo de casos de uso (MCU) é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos (ator) ao sistema que interagem com ele. O MCU é um modelo de análise que representa um refinamento dos requisitos funcionais do sistema em desenvolvimento. O MCU representa os possíveis usos de um sistema, conforme percebidos por um observador externo a este sistema. Cada um destes casos de usos está associado a um ou mais requisitos funcionais identificados para o sistema. A construção desse modelo envolve a definição de diversos componentes: casos de uso, atores e relacionamentos entre eles. Casos de Uso Por definição, um caso de uso (use case) é a especificação de uma sequencia completa de interações entre um sistema e um ou mais agentes externos (atores) a esse sistema. Um caso de uso representa um relato de uso de certa funcionalidade do sistema em questão, sem revelar a estrutura e o comportamento interno desse sistema. Um modelo de casos de uso típico contém vários casos de uso. A quantidade exata de casos de uso obviamente depende da complexidade do sistema em desenvolvimento: quanto mais complexo o sistema, maior a quantidade de casos de uso. Cada caso de uso de um sistema se define pela descrição narrativa (textual) das interações que ocorrem entre o(s) elemento(s) externo(s) e o sistema. Podemos dizer que há três dimensões em que o estilo de descrição de um caso de uso pode variar. Essas dimensões são o formato, o grau de detalhamento e o grau de abstração. Formato: diz respeito à estrutura utilizada para organizar a sua narrativa textual. Os formatos comumente utilizados são o contínuo, o numerado e o tabular; Grau de Detalhamento: pode variar desde o mais sucinto até a descrição com vários detalhes (expandido); Grau de Abstração: diz respeito a existência ou não de menção a aspectos relativos à tecnologia durante a descrição desse caso de uso. Em relação ao grau de abstração um caso de uso pode ser real ou essencial. Exemplo de Descrição Contínua Realizar Saque Este caso de uso inicia quando o Cliente chega ao caixa eletrônico e insere seu cartão, em seguida o sistema requisita a senha do Cliente. Após o Cliente fornecer sua senha e esta ser validada, o sistema exibe as seguintes opções de operações possíveis: Saque, Depósito, Empréstimos e Pagamento de Contas. O Cliente opta por realizar um saque, assim o sistema requisita o total a ser sacado, após o cliente informar valor a ser sacado, o sistema fornece a quantia desejada e imprime o recibo para o Cliente. O Cliente retira a quantia e o recibo, e o caso de uso termina. Exemplo de Descrição Numerada Realizar Saque 1. Cliente insere seu cartão no caixa eletrônico. 2. Sistema apresenta solicitação de senha. 3. Cliente digita senha. 4. Sistema valida a senha e exibe menu de operações disponíveis. 5. Cliente indica que deseja realizar um saque. 6. Sistema requisita quantia a ser sacada. 7. Cliente fornece o valor que deseja sacar. 8. Sistema fornece a quantia desejada e imprime o recibo do cliente. 9. Cliente retira a quantia e o recibo, e o caso de uso termina. Profa. MSc. Viviane Guimarães Ribeiro 34

35 Exemplo de Descrição Tabular Realizar Saque Cliente Sistema Insere seu cartão no caixa eletrônico. Apresenta solicitação de senha. Digita senha. Solicita realização de saque. Fornece o valor da quantia que deseja sacar. Retira a quantia e o recibo. Valida a senha e exibe menu de operações disponíveis. Requisita quantia a ser sacada. Fornece a quantia desejada e imprime o recibo para o Cliente. Exemplo de Descrição Essencial e Numerada Realizar Saque 1. Cliente fornece sua identificação. 2. Sistema identifica o usuário. 3. Sistema fornece opções disponíveis para movimentação da conta. 4. Cliente indica que deseja realizar um saque. 5. Sistema requisita quantia a ser sacada. 6. Cliente fornece o valor que deseja sacar. 7. Sistema fornece a quantia desejada e imprime o recibo do cliente. 8. Cliente retira a quantia e o recibo, e o caso de uso termina. Cenários Geralmente a funcionalidade de um sistema descrita por um caso de uso tem diversas maneiras de ser utilizada. Um cenário é a descrição de uma das maneiras pelas quais um caso de uso pode ser utilizado. Outra maneira de ver um cenário é como a descrição de um episódio de utilização de alguma funcionalidade do sistema. Exemplo de cenário para um caso de uso de compra pela Internet O cliente seleciona um conjunto de produtos do catálogo da loja. Após selecionar os produtos que seja comprar, o cliente indica o desejo de realizar o pagamento por cartão de crédito. O sistema informa que o último produto escolhido está fora do estoque. O cliente pede para que o sistema feche o pedido sem o item que está fora de estoque. O sistema solicita os dados do cliente para realização do pagamento. O cliente fornece o número do cartão, a data de expiração, além de informar o endereço de entrega do pedido. O sistema apresenta o valor total, a data de entrega e uma identificação do peido para futuro rastreamento. O sistema também envia um correio eletrônico como confirmação do pedido de compra. O sistema envia os dados do pedido para o sistema de logística da empresa. Uma coleção de cenários para um caso de uso pode ser utilizada posteriormente na fase de testes quando o caso de uso estiver sendo testado para verifica a existência de erros na implementação do sistema. Atores É qualquer elemento externo ao sistema que interage com o mesmo. Atores de um sistema podem ser agrupados em diversas categorias: Cargos; Organizações ou divisões de uma organização; Outros sistemas de software; Equipamentos com os quais o sistema deve se comunicar. Profa. MSc. Viviane Guimarães Ribeiro 35

36 Normalmente um ator inicia a sequência de interações correspondente a um caso de uso. Uma situação menos frequente, mas também possível, é um evento interno acontecer para que a sequência de interações do caso de uso em questão seja acionada. Levando em conta que um ator é um papel representado por algo (ou alguém) em relação ao sistema, é uma boa prática de modelagem fazer com que o nome dado a esse ator lembre o seu papel, em vez de lembrar que o representa. Um ator pode participar de muitos casos de uso. Do mesmo modo, um caso de uso pode envolver a participação de vários atores, o que resulta na classificação dos atores primários e secundários. Um ator primário é aquele que inicia uma sequência de interações de um caso de uso. São eles os agentes externos para os quais o caso de uso traz benefício direto. Já um ator secundário supervisiona, opera, mantém ou auxilia na utilização do sistema pelo ator primário Diagrama de Caso de Uso - DCU O diagrama de caso de uso corresponde a uma visão externa de alto nível do sistema. Esse diagrama representa graficamente os atores, casos de uso e relacionamentos entre esses elementos. Tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidade do sistema. Nesse sentido, a finalidade de um DCU é apresentar uma espécie de Diagrama de Contexto, pois apresenta os elementos externos de um sistema e as maneira segundo as quais eles a utilizam. Ator Caso de Uso Relacionamento de comunicação Profa. MSc. Viviane Guimarães Ribeiro 36

37 Sistema de Biblioteca A UML define quatro tipos de relacionamentos no modelo de caso de uso: Comunicação; Inclusão; Extensão; Generalização/Herança; Um relacionamento de comunicação informa a que caso de uso o ator está sendo associado, o que significa que esse ator interage (troca informações) com o sistema por meio daquele caso de uso. O relacionamento de inclusão existe somente entre casos de uso. Quando dois ou mais casos de uso incluem uma sequência comum de interação, essa sequência comum pode ser descrita em um outro caso de uso. A partir daí, os casos de uso do sistema podem usar esse caso de uso comum. Profa. MSc. Viviane Guimarães Ribeiro 37

38 Sistema de Controle de Transações Bancárias O relacionamento de exclusão é utilizado para modelar situações em que diferentes sequências de interações podem ser inseridas em um caso de uso, chamado caso de uso estendido. Cada uma dessas diferentes sequências representa um comportamento opcional, ou seja, um comportamento que só ocorre sob certas condições, ou cuja realização depende da escolha de um ator. Sistema de Vendas O relacionamento de generalização/herança pode existir entre dois casos de uso ou entre dois atores. Quando a generalização acontece entre casos de uso, a sequência de comportamento feitas no caso de uso original são reutilizadas pelos casos de uso herdeiro. Somente os comportamentos necessários ao caso de uso herdeiro precisam ser redefinidos. Profa. MSc. Viviane Guimarães Ribeiro 38

39 Sistema de Gerenciamento de Pagamentos Na generalização entre atores, o ator herdeiro possui o mesmo comportamento em relação ao sistema que o ator do qual ele herda. Sendo que, o ator herdeiro pode participar em casos de uso em que o ator do qual ele herda não participa. Sistema de Gestão Bibliotecária Identificação dos elementos do DCU Atores e casos de uso são identificados a partir de informações coletadas no levantamento de requisitos. Durante essa fase, os analistas de sistemas devem identificar as atividades do processo de negócio que devem ser automatizadas pelo sistema a ser construído. Os analistas também devem identificar quais os elementos que interagem naqueles processos. Não há uma regra geral que indique quantos casos de uso e atores são necessários para descrever um sistema. Note também que as identificações de atores e de casos de uso são atividade que se intercalam. Profa. MSc. Viviane Guimarães Ribeiro 39

40 Identificação de Atores Para identificar os atores, o analista de sistemas deve tentar identificar quais as fontes de informações a serem processadas e quais são os destinos das informações geradas pelo sistema. Para identificar os atores podemos fazer as seguintes perguntas básicas: Quem são os clientes? Quem utilizará as funcionalidades principais do sistema? Quem necessita administrar e manter o sistema funcionando? Quem precisará de suporte do sistema para fazer suas tarefas diárias? Quem fornece suporte ou manutenção para o sistema? Com quais dispositivos de hardware o sistema precisará interagir? O sistema interage com outros sistemas? Entre outras... Identificação de Casos de Uso A partir das listas (inicial) de atores, deve-se passar à identificação dos casos de uso. Nesta identificação, pode-se distinguir entre dois tipos de casos de uso: Primário: representa os objetivos dos atores; Secundários: aquele que não traz benefício direto para os atores, mas que é necessário para que o sistema funcione adequadamente. Casos de Uso Primários Esses casos de uso representam os processos da empresa que estão sendo automatizados pelo sistema de software. A seguir são enumeradas algumas perguntas para as quais o analista de sistemas deve procurar respostas com o intuito de identificar os casos de uso: Quais são as necessidades e objetivos de cada ator em relação ao sistema? Que informações o sistema deve produzir? O sistema deve realizar alguma ação que ocorre regularmente no tempo? Para cada requisito funcional, existe um (ou mais) caso(s) de uso para atendêlo? O modelador também pode utilizar outras técnicas de identificação: Caso de uso Oposto ; Caso de uso que precede/sucede a outro caso de uso; Caso de uso temporal; Caso de uso relacionado a uma condição interna. Casos de Uso Secundários Estes se encaixam nas seguintes categorias: Manutenção de cadastros; Manutenção de usuários; Gerenciamento de acesso; Manutenção de informações provenientes de outros sistemas Construção do DCU Os diagramas de casos de uso devem servir para dar suporte à parte textual do modelo, fornecendo uma visão de alto nível. Se o sistema sendo modelado não for tão complexo, pode ser criado um único DCU. Em sistemas complexos, representar todos os casos de uso do sistema em um único DCU talvez o torne um tanto ilegível. A alternativa para esse problema é criar vários diagramas (de acordo com as necessidades de visualização) e agrupá-lo em pacotes: Profa. MSc. Viviane Guimarães Ribeiro 40

41 Todos os casos de uso para um ator; Todos os casos de uso a serem implementados em um ciclo de desenvolvimento; Todos os casos de uso de uma área (departamento, seção) específica da empresa. O uso de pacotes permite formar grupos de casos de uso e atores de tal sorte que o MCU possa ser compreendido por partes. Profa. MSc. Viviane Guimarães Ribeiro 41

42 Profa. MSc. Viviane Guimarães Ribeiro 42

43 Documentação de Atores A documentação de atores é relativamente simples. Uma breve descrição (uma ou duas frases) para cada ator deve ser adicionada ao modelo de casos de uso. O nome escolhido para um ator deve lembrar o papel desempenhado pelo mesmo no sistema. Documentação de Atores: Sistema Acadêmico Aluno: indivíduo que está matriculado na faculdade, que tem interesse em se inscrever em disciplinas do curso. Professor: indivíduo que leciona disciplinas na faculdade. Coordenador: pessoa interessada em agendar as alocações de turmas e professores, e visualizar o andamento de inscrições de alunos. Departamento de Registro Escolar (DRE): departamento da faculdade interessado em manter informações sobre os alunos matriculados e sobre seu histórico escolar. Sistema de Recursos Humanos: este sistema legado é responsável por fornecer informações cadastrais sobre os professores. Sistema de Faturamento: este sistema legado tem interesse em obter informações sobre inscrições dos alunos para realizar o controle de pagamento de mensalidades. Documentação de Casos de Uso Nome O primeiro item que deve constar da descrição de um caso de uso é o seu nome. Este deve ser o mesmo utilizado no DCU. Cada caso de uso deve ter um nome único. Identificador O identificador é um código único para cada caso de uso que permite fazer referência cruzada entre diversos documentos relacionados com o MCU. Uma convenção de nomenclatura é usar o prefixo CSU seguido de um número sequencial. Ex: CSU01. Importância A definição da categoria de importância é atribuída ao caso de uso. Risco Alto e Prioridade Alta: casos de uso nesta categoria são os mais críticos. Devem ser considerados o quanto antes. Rico Alto e Prioridade Baixa: embora os casos de uso nesta categoria tenham risco alto, é necessário, antes de começar a considerá-lo, negociar com o cliente em relação a sua verdadeira necessidade. Risco Baixo e Prioridade Alta: embora os casos de uso tenham prioridade alta, é necessário ter em mente que os casos de uso de mais alto risco devem ser considerados primeiro. Risco Baixo e Prioridade Baixa: em situações em que o desenvolvimento do sistema está atrasado, estes casos de uso são os primeiros a serem cortados. Sumário Uma pequena declaração do objetivo do ator ao utilizar o caso de uso (no máximo duas frases). Ator Principal O nome do ator que inicia o caso de uso. Um caso de uso possui apenas um ator primário. Atores Secundários Os nomes dos demais elementos externos participantes do caso de uso. Um caso de uso possui zero ou mais atores secundários. Precondições Uma precondição de um caso de uso define que hipóteses são assumidas como verdadeiras para que o caso de uso tenha início. Este item da descrição pode conter zero ou mais precondições. Fluxo Principal O fluxo principal descreve o que normalmente acontece quando o caso de uso é executado sem a ocorrência de erros. Profa. MSc. Viviane Guimarães Ribeiro 43

44 Fluxos Alternativos Representa um comportamento alternativo geralmente devido a uma escolha do usuário ou processamento provocado por um estado diferente do esperado no Fluxo Principal. Fluxos de Exceção Descreve o que acontece quando algo inesperado ocorre durante a realização do caso de uso em um determinado ponto do Fluxo Principal ou Alternativo. Pós Condição Indica o estado que o sistema alcança após o caso de uso ter sido realizado. Regras de Negócio Serve para fazer uma referência cruzada a uma ou mais regras de negócio. Histórico Este item pode declarar informações como: o autor do caso de uso; a data em que ele foi criado; além de eventuais modificações no seu conteúdo. Notas de Implementação Serve somente para capturar ideias de implementação relevantes que passam pela cabeça do modelador (não é a especificação da solução). Realizar Inscrição (CSU01) Sumário: Aluno usa o sistema para realizar inscrição em disciplina. Ator Primário: Aluno Atores Secundários: Sistema de Faturamento Precondições: O Aluno está identificado pelo sistema. Fluxo Principal 1. O Aluno solicita a realização de inscrição. 2. O sistema apresenta as disciplinas para as quais o aluno tem pré-requisitos (conforme a RN03), excetuando-se as que já tenha cursado. 3. O Aluno define a lista de disciplina que deseja cursar no próximo semestre letivo e as relaciona para inscrição. 4. Para cada disciplina selecionada, o sistema designa o aluno para uma turma que apresente uma oferta para tal disciplina. 5. O sistema informa as turmas para as quais o Aluno foi designado. Para cada turma, o sistema informa o professor, os horários e os respectivos locais das aulas de cada oferta de disciplina. 6. O Aluno confere as informações fornecidas. Aqui, é possível que o caso de uso retorne ao passo 3, conforme o Aluno queria revisar (inserir ou remover itens) da lista de disciplinas a cursar. 7. O sistema registra a inscrição de Aluno, envia os dados sobre a mesma para o Sistema de Faturamento e o caso de uso termina. Fluxo Alternativo (4): Inclusão em lista de espera a) Se não há oferta disponível para alguma disciplina selecionada pelo aluno (conforme a RN02), o sistema reporta o fato e fornece a possibilidade de inserir o Aluno em uma lista de espera. b) Se o Aluno aceitar, o sistema o insere na lista de espera e apresenta a posição na qual o aluno foi inscrito na lista. O caso de uso retorna ao passo 4. c) Se o Aluno não aceitar, o caso de uso prossegue a partir do passo 4. Fluxo de Exceção (4): Violação de RN01 a) Se o aluno atingiu a quantidade máxima de inscrições possíveis em um semestre letivo (conforme RN01), o sistema informa ao aluno a quantidade de disciplinas que ele pode selecionar, e o caso de uso retorna ao passo 2. Pós-condições: O Aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas, ou foi adicionado a uma ou mais listas de espera. Regras de Negócio: O RN01, RN02, RN03. Profa. MSc. Viviane Guimarães Ribeiro 44

45 Manter Disciplina (CSU05) Sumário: DRE realiza o cadastro (inclusão, remoção, alteração e consulta) dos dados sobre disciplinas. Ator Primário: DRE Fluxo Principal 1. DRE requisita a manutenção de disciplinas. 2. O sistema apresenta as operações que podem ser realizadas: a inclusão de uma nova disciplina, a alteração dos dados de uma disciplina, a exclusão de uma disciplina e a consulta de disciplinas. 3. O DRE indica a opção a realizar ou opta por finalizar o caso de uso. 4. O DRE seleciona a operação desejada: Inclusão, Exclusão, Alteração ou Consulta. 5. Se o DRE deseja continuar com a manutenção, o caso de uso retorna ao passo 2; caso contrário, o caso de uso termina. Fluxo Alternativo (4): Inclusão a) O DRE requisita a inclusão de uma disciplina. b) O sistema apresenta um formulário em branco para que os detalhes da disciplina (código, nome e quantidade de créditos) sejam incluídos. c) O DRE fornece os detalhes da nova disciplina. d) O sistema apresenta uma lista de disciplinas para que o DRE selecione as que são pré-requisitos para a disciplina a ser criada. e) O DRE define zero ou mais disciplinas como pré-requisitos. f) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a nova disciplina; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação. Fluxo Alternativo (4): Remoção a) O DRE seleciona uma disciplina e requisita ao sistema que a remova. b) Se a disciplina pode ser removida, o sistema realiza a remoção; caso contrário, o sistema reporta o fato. Fluxo Alternativo (4): Alteração a) O DRE altera um ou mais dos detalhes sobre uma disciplina e requisita a sua atualização. b) O sistema verifica a validade dos dados e, se eles forem válidos, altera os dados na lista de disciplinas da faculdade. Fluxo Alternativo (4): Consulta a) O DRE solicita a realização de uma consulta sobre a lista de disciplinas. b) O sistema apresenta uma lista com os códigos de todas as disciplinas, permitindo que o usuário selecione a disciplina desejada. c) O DRE seleciona uma disciplina. d) O sistema apresenta os detalhes da disciplina e seus pré-requisitos (se existirem) no formulário de disciplinas. Pós-condições: Uma disciplina foi inserida ou removida, ou seus detalhes foram alterados Complexidade dos Casos de Uso Os casos de uso podem ser classificados de acordo com sua complexidade da seguinte forma: Processos de Negócio (Condução): Modelam os principais processos de negócio da empresa; CRUD (Configuração): As quatro operações básicas sobre uma unidade de informação criar, consultar, atualizar e deletar; Relatório (Análise): Apresentar informações que já estão disponíveis. Profa. MSc. Viviane Guimarães Ribeiro 45

46 Tipo de Casos de Uso Concreto: Iniciado diretamente por um Ator. Abstrato: Não iniciado diretamente por um Ator. Geralmente relacionado a outro Caso de Uso. Concreto Abstrato Abstrato Abstrato Profa. MSc. Viviane Guimarães Ribeiro 46

47 7. Diagrama de Atividades Os diagramas de atividades são empregados para fazer a modelagem de aspectos dinâmicos do sistema. São utilizados para: Modelagem dos processos de negócio neste caso, o objetivo é entender melhor um determinado problema, ou seja, entender o comportamento do sistema no decorrer de diversos casos de uso. Modelagem da lógica de um caso de uso usado como um complemento da descrição do caso de uso. Os fluxos principal, alternativo e de exceção podem ser representados em um único diagrama de atividades. Note, entretanto, que casos de uso são descritos na perspectiva dos atores, enquanto diagramas de atividade descrevem atividades internas do sistema. Modelagem da lógica de uma operação complexa em alguns casos, notadamente quando uma operação de uma classe de controle implementa uma regra de negócio, pode haver a necessidade de descrever a lógica dessa operação ou da própria regra de negócio. 7.1 Elementos de um diagrama de atividades Símbolo Significado Início Fim Direção de Fluxo Atividade em realização Tomada de decisão Profa. MSc. Viviane Guimarães Ribeiro 47

48 Barras de sincronização (bifurcação ou união) Exemplo: Tomada de Decisão Profa. MSc. Viviane Guimarães Ribeiro 48

49 Exemplo: Paralelismo de Atividade Bifurcação União Bifurcação União Profa. MSc. Viviane Guimarães Ribeiro 49