Curso de Sistemas de Informação. Karla Donato Fook DESU / DComp. Modelagem de Dados UML

Transcrição

1 Curso de Sistemas de Informação Karla Donato Fook DESU / DComp 2017 Modelagem de Dados UML 2 1

2 Eduardo Bezerra Editora Campus/Elsevier Porcentagem de projetos que terminam dentro do prazo estimado: 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. Fonte: Chaos Report (1994) Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 4 2

3 Um processo de desenvolvimento de software (PDS) compreende todas as atividades necessárias para definir, desenvolver, testar e manter um produto de software. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 5 Exemplos ICONIX RUP EUP XP OPEN Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 6 3

4 Alguns objetivos 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. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 7 Atividades típicas de um PDS O componente humano em um PDS Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 8 4

5 Levantamento de requisitos Análise de requisitos Projeto Implementação Testes Implantação Foco do livro Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 9 Gerentes de projeto Analistas Projetistas Arquitetos de software Programadores Clientes Avaliadores de qualidade Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 10 5

6 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 11 O desenvolvimento de um software pode ser facilitado através do uso de ferramentas que auxiliam na construção de modelos na integração do trabalho de cada membro da equipe no gerenciamento do andamento do desenvolvimento etc. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 12 6

7 Há diversos sistemas de software que são utilizados para dar suporte ao desenvolvimento de outros sistemas Um tipo bastante conhecido de ferramenta de suporte são as ferramentas CASE CASE: Computer Aided Software Engineering Outras ferramentas importantes fornecem suporte ao gerenciamento desenvolver cronogramas de tarefas definir alocações de verbas monitorar o progresso e os gastos gerar relatórios de gerenciamento etc. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 13 Criação e manutenção da consistência entre estes diagramas Depuração de código fonte Relatórios de testes Testes automáticos Gerenciamento de versões Verificação de desempenho Verificação de erros em tempo de execução Gerenciamento de mudanças nos requisitos Prototipagem Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 14 7

8 15 Auxilia o entendimento do ambiente no qual o sistema irá operar Fatos, regras e restrições relevantes do domínio do problema Ajuda a visualizar um sistema como ele é ou como se deseja que ele seja Permite especificar o comportamento e a estrutura de um sistema 16 8

9 Oferece uma representação que guiará a construção do sistema Documenta as decisões tomadas pela avaliação das alternativas propostas Auxilia Avaliação dos riscos Definição do problema Gerenciamento do projeto 17 A utilização de uma modelagem visual facilita a visualização, e, por conseguinte, a criação de um melhor modelo mais flexível, mais robusto e principalmente mais reutilizável Necessidade de estabelecer uma padronização para facilitar a comunicação entre os analistas (responsáveis pelo levantamento dos requisitos) e a equipe de desenvolvimento (responsáveis pela implementação) 18 9

10 Um sistema tem geralmente muitas classes e nem sempre estas classes são vistas por uma só pessoa, isto é, dependendo do nível hierárquico desta pessoa, formas diferentes de apresentar uma diagrama de classes devem existir 19 Exemplos Um cliente não quer saber o que é uma classe, mas apenas compreender determinados conceitos Um gerente de um projeto não precisa ver detalhes de um modelo Um time de desenvolvimento precisa ver um diagrama e compreender uma série de detalhes 20 10

11 É uma linguagem para visualização, especificação, construção e documentação de artefatos de um software em desenvolvimento NÃO é Análise ou Projeto OO Notação padrão de diagramação Estabelece como construir e ler modelos. Não estabelece que modelos e nem quem vai construir É um padrão da indústria, controlado pela OMG (Object Management Group) 22 11

12 Ivar Jacobson Grady Booch Jim Rumbaugh Começou a ser definida a partir de uma tentativa de Jim Rumbaugh e Grady Booch de combinar dois métodos populares de modelagem OO: Booch e OMT (Object Modeling Language) 23 Ivar Jacobson Grady Booch Jim Rumbaugh Mais tarde, Ivar Jacobson, o criador do método Objectory, uniu-se aos dois para a concepção da primeira versão da linguagem UML (Unified Modeling Language) 24 12

13 Ivar Jacobson Grady Booch Jim Rumbaugh UML foi adotada em 1997 pela OMG (Object Management Group) 25 UML permite modelar Elementos ou Itens Relacionamentos Diagramas 26 13

14 Estruturais classes, interfaces, componentes Comportamentais interações, máquinas de estado Grupos de elementos pacotes, subsistemas Outros anotações 27 Dependências Associações Generalizações Implementações (Realização) 28 14

15 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 29 A UML é independente do processo de desenvolvimento Vários processos podem utilizar a UML para modelagem de um sistema OO Os artefatos de software construídos através da UML evoluem à medida que o as iterações são realizadas A cada iteração, novos detalhes são adicionados a esses artefatos Além disso, a construção de um artefato fornece informações para adicionar detalhes a outros Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 30 15

16 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 31 Um modelo é representado por um ou mais diagramas Um diagrama pode ser representado de várias formas, dependendo de quem irá interpretá-lo 32 16

17 33 Um diagrama provê uma representação parcial do sistema Ajuda a compreender a arquitetura do sistema em desenvolvimento 34 17

18 Estáticos ou Estruturais Diagramas de Casos de Uso Diagramas de Classes Diagramas de Objetos Diagramas de Pacotes Dinâmicos de Comportamento Diagramas de Interação Diagramas de Sequência Diagramas de Colaboração Diagramas de Estado (Statechart) Diagramas de Atividade 35 A UML é uma notação. Na Orientação a Objetos, há questões mais cruciais para se aprender, como pensar em objetos e projetar sistemas orientados a objetos 36 18

19 Componentes Blocos de construção Regras que restringem como os blocos de construção podem ser associados Mecanismos de uso geral 37 Estereótipos Notas explicativas Etiquetas Restrições Pacotes OCL - Object Constraint Language (Linguagem de Restrição de Objetos) 38 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 19