Prof. Esp. Fabiano Taguchi

Transcrição

1 UML Prof. Esp. Fabiano Taguchi UML COMPETÊNCIA: Conhecer e desenvolver estudos de caso usando modelagem orientada a objeto. HABILIDADE: Conhecer os fundamentos do desenvolvimento de um sistema e as ferramentas de análise e desenvolvimento de projetos de Sistemas de Informação. CARGA HORÁRIA: 44 horas 1

2 INFORMAÇÕES IMPORTANTES ATENÇÃO COM AS FALTAS E O CONTEÚDO! AVALIAÇÃO IRÁ ACONTECER NO DECORRER DAS AULAS. EXERCÍCIOS DURANTE AS AULAS APRESENTAÇÃO DA MODELAGEM DE UM SISTEMA AULAS SERÃO DIVIDIDAS ENTRE TEORIA E PRÁTICA. DESENVOLVIMENTO DE SOFTWARES 2

3 CRISE DO SOFTWARE A indústria do software tem tido uma crise que a acompanha há quase 30 anos. Esses problemas abrangem: Desenvolvimento; Testes; Manutenção. CRISE DO SOFTWARE Custos do hardware diminuem Custos do software aumentam Os desafios do softwares são classificados em: Confiabilidade; Preço e desempenho; Sistemas críticos. 3

4 A VERDADE É QUE: A sofisticação do software ultrapassou a capacidade de construção, que também não consegue acompanhar a demanda por novos softwares. Por que? Planejamento? Documentação? Testes? ENGENHARIA DE SOFTWARE Engenharia de software é uma disciplina que estuda todos os aspectos da produção de softwares. Diferindo em aspectos como: Software é desenvolvido, não produzido; Software não se desgasta; Produzido para um cliente específico. 4

5 ASPECTOS DE UM BOM SOFTWARE Facilidade de manutenção; Confiança; Eficiência; Usabilidade. ATIVIDADES EM UM PROJETO 1. Especificação de requisitos; 2. Projeto de software 3. Implementação 4. Validação do software 5. Evolução do software 5

6 AVALIAÇÃO DE APRENDIZAGEM 01 - Por que leva tanto tempo para concluir um sistema de software? 02 Por que os custos são tão altos? 03 - Por que não achamos todos os erros antes de entregar o software ao cliente? 04 - Por que gasta-se tantos recursos para manter sistemas existentes (antigos)? MODELOS DE PROCESSOS 6

7 MODELO CASCATA Consiste em atividades sequenciais, com documentação rígida. Este modelo é pouco usado na prática, pois: Raramente o cliente consegue estabelecer todos os requisitos de início; Difícil de se adequar as mudanças; Versão só pode ser visualizada ao final do projeto. MODELO CASCATA 7

8 DESENVOLVIMENTO INCREMENTAL As atividades são intercaladas, permitindo que seja passado um feedback imediato ao cliente. Neste modelo as mudanças tendem a corromper a modularidade do sistema, tornando a gerencia deste projeto algo bastante complexo. No desenvolvimento incremental é possível começar a desenvolver o sistema pelas partes de menos complexidade e mais claras para o cliente. DESENVOLVIMENTO INCREMENTAL 8

9 BASEADO EM REUSO Este processo baseia-se na integração dos componentes reusáveis, com isso, diminui a quantidade de software a ser desenvolvido, os custos e os riscos. Em contra partida este modelo torna a gerencia bastante complexa. DEFINIÇÃO DE REQUSIITOS 9

10 REQUISITOS São os serviços fornecidos pro um sistema e são classificados em requisitos funcionais e não funcionais. FUNCIONAIS = Descrevem as funcionalidade e serviços NÃO FUNCIONAIS = Definem propriedades e restrições REQUISITOS FUNCIONAIS Este requisitos documentam como o sistema deve reagir a entradas específicas e como devem se comportar em determinadas situações. Exemplos: Todo usuário poderá fazer consultas em um banco de dados. Cada nota fiscal deverá possuir um código. Sistema deve notificar o requisitante por quando a requisição estiver disponível para retirada. 10

11 REQUISITOS NÃO FUNCIONAIS Mapeiam aspectos qualitativos de um software: performance, segurança, perspectiva do usuário, comunicação e usabilidade. Exemplos: A interface do usuário deverá sem escrito em HTML simples; Todos os documentos devem seguir o padrão de nome XYZ-00; O tempo de resposta de uma requisição deve ser de 0,2 segundos. ENGENHARIA DE REQUISITOS 11

12 ETAPAS DA ENGENHARIA DE REQUISITOS Quatro são as fases: 1. Estudo de viabilidade; 2. Elicitação de requisitos; 3. Especificação de requisitos 4. Validação de requisitos ESTUDO DE VIABILIDADE Todo sistema novo deve começar por um estudo de viabilidade, no qual deve ser respondidas perguntas como: O sistema pode ser implementado com a tecnologia atual dentro das restrições de custo e prazo? O sistema pode ser integrado a outros sistemas em operação? Como a organização se comportaria sem este sistema? Que processos serão auxiliados por esse novo sistema? 12

13 ELICITAÇÃO E ANÁLISE DE REQUISITOS ESPECIFICAÇÃO DOS REQUISITOS Construir o documento com os requisitos identificados. 13

14 VALIDAÇÃO DE REQUISITOS Esta etapa serve para mostrar que os requisitos realmente definem o sistema que o cliente deseja, nesta etapa é possível verificar os problemas com os requisitos, com verificações de: Validade; Consistência; Completude; Realismo. EXERCÍCIOS DE APRENDIZAGEM 14

15 EXERCÍCIOS DE APRENDIZAGEM UML 15

16 ORIENTAÇÃO A OBJETO Abstração Classes Objetos Atributos Métodos Método construtor Herança Polimorfismo Sobrecarga Encapsulamento Interface MODELAGEM O que é modelagem? Por que precisamos usar modelos? 16

17 HISTÓRICO A UML surgiu entre os anos de 1998 e Consiste em uma linguagem visual para especificação de sistemas orientados a objetos, independente da linguagem de programação a ser usada. Dados (Estrutural) Operações (Funcional) Eventos (Temporal) HISTÓRICO Em seu início notações diferentes eram usados para descrever projetos orientados a objetos, a UML acabou por se tornar a integração dessas várias notações. É uma linguagem não proprietária; Não é uma metodologia de desenvolvimento. 17

18 FERRAMENTAS Existe uma gama de ferramentas muito grande para modelagem a partir da UML, dentre as mais conhecidas: Rational Rose; Enterprise Architect; Astah; StarUML; ArgoUML. OBJETIVO DA UML Modelar sistemas usando os conceitos de orientação a objetos; Ajudar a equipe de projeto a visualizar um sistema como ele pretende ser; Auxiliar a especificar a estrutura e o comportamento do sistema ao passar do tempo; Proporcionar um modelo que sirva de guia para a construção do sistema; 18

19 CONCEITOS UML Dois conceitos iniciais são importantes : DIAGRAMA: É uma visão de um modelo. MODELO: É a descrição completa de um sistema em uma determinada perspectiva. ESTRUTURAÇÃO UML 13 DIAGRAMAS DIAGRAMAS ESTRUTURAIS Diagrama de classes, objetos e pacotes; Diagrama de implantação, componentes e estruturação composta. DIAGRAMAS COMPORTAMENTAIS Casos de uso e diagrama de atividades; Diagrama de máquinas de estado. DIAGRAMAS DE INTERAÇÃO Diagramas de sequência, comunicação, tempo e visão geral da interatividade. 19

20 EXERCÍCIOS EXERCÍCIO Em grupo de até 04 pessoas, liste 10 requisitos funcionais e 10 requisitos não funcionais para os seguintes projetos de software: Posto de combustível; Venda de passagens; Pizzaria; Escola de idiomas; Padaria. 20

21 DEFINIÇÃO DO SISTEMA POSTO DE COMBUSTÍVEL O caso em questão será o desenvolvimento de um sistema para controle de pagamentos de abastecimento em um posto de combustível localizado no centro da cidade. Este sistema deverá armazenar todas as informações necessárias para que se possa fazer a venda de combustível ao cliente. DEFINIÇÃO DO SISTEMA VENDA DE PASSAGENS O sistema para venda de passagens atenderá uma empresa de transportes em específico, este sistema tem como objetivo fazer a venda e reservas de passagens rodoviárias. 21

22 DEFINIÇÃO DO SISTEMA PIZZARIA Uma pizzaria da cidade vai começar a trabalhar com tele entregas, para isso necessita de um sistema para controle de pedidos. O objetivo do sistema é gerenciar os pedidos de pizza e repassar ao setor de produção. DEFINIÇÃO DO SISTEMA ESCOLA DE IDIOMAS Uma escola de idiomas foi criada por dois amigos, e precisar de um sistema para matricular os alunos. O objetivo deste sistema é que se faça o cadastro e matrícula dos alunos. 22

23 DEFINIÇÃO DO SISTEMA PADARIA Para uma padaria, o sistema a ser desenvolvido será instalado apenas no caixa da padaria, ou seja, o objetivo principal deste sistema é fazer a gestão da cobrança das comandas. 23