Cenário atual UML Histórico

Transcrição

1 a UML (Unified Modeling Language) Roteiro Cenário atual UML Histórico 1

2 Qual é o cenário atual? Quais são suas necessidades para o sistema? Preciso de um sistema que controle todas as vendas de meus produtos... Levantamento de Requisitos Qual é o cenário atual? Validação com o Usuário Usuário não valida de acordo, pois não compreende o que foi modelado. 2

3 Qual é o cenário atual?. Excesso de documentação ou nenhuma Desenvolvimento Qual é o cenário atual?. Técnica utilizada Desenvolvimento 3

4 Qual é o cenário atual?. Técnica utilizada Desenvolvimento Program and Pray Ou Quick and Dirty Qual é o cenário atual?. Cronograma apertado -> Prazo estourado Desenvolvimento 4

5 Qual é o cenário atual? Entrega Final Cliente insatisfeito. Horas infindáveis de manutenção corretiva, etc... O que concluir até o momento? 5

6 ... Crise do Sofware... Prazos ultrapassados Custos acima do previsto Não atendimento dos requisitos do usuário Elevado custo de manutenção... Crise do Sofware... 1/3 dos projetos são cancelados 2/3 dos projetos estrapolam o orçamento Custo hardware x software 1970 = 8: = 2:8 Hoje = 1:9 6

7 ... Crise do Sofware... Custo com manutenção HP (50% do pessoal envovido com manutenção) VW = 80% O que as empresam esperam... 7

8 O que as empresam esperam... Melhor flexibilidade e adaptabilidade; Possibilitando satisfazer novos requisitos de negócios rapidamente facilmente Melhor manutenabilidade; Possibilitando atualizar uma aplicação, mas minimizando o impacto da maioria das mudanças O que as empresam esperam... Melhor reusabilidade; Possibilitando rapidamente montar aplicações únicas e dinâmicas Melhor aproveitamento do legado; Possibilitando o aproveitamento do legado corporativo Não queremos jogar fora o que a empresa já tem! 8

9 O que as empresam esperam... Melhor interoperabilidade Possibilitando integrar 2 aplicações executando em plataformas diferentes Melhor escalabilidade Possibilitando distribuir e configurar a execução da aplicação para satisfazer vários volumes de transação O que as empresam esperam... Menor tempo de desenvolvimento; Possibilitando viver on Internet Time e com baixo orçamento Melhor robustez; Possibilitando ter soluções com menos defeitos Menor risco; Possibilitando tudo que falamos acima e ainda não se arriscar a ter projetos fracassados 9

10 Então... O que devemos fazer????? Estudar novas metodologias de desenvolvimento de software! Quais são as elas e quais são as melhores?? Tendências... Fábrica de Software Extreme Programming CMM RUP Frameworks 10

11 Tendências... Métricas para estimativas de esforço Pontos de Função Use-Case Points Automatização de Testes Software baseado em Componentes Design Pattenrs Controle de Versões de Software Reutilização de Código Tendências... UML Ferramentas de Workflow 11

12 Análise e Projeto de Sistemas Orientados a Objetos O que é Análise? O que é Projeto? 12

13 Análise X Projeto Diferenças entre análise e projeto: tem mais do que uma definição empregada. Primeira Alternativa: A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema (o que deveser feito). É uma atividade de investigação. O projeto modela a solução e consiste das atividades de criação (como pode ser feito) Análise X Projeto Segunda Alternativa A análise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar. O projeto inclui as atividades que resultam em informação que interessa apenas ao programador. Com essa definição, a análise invade um pouco o lado da solução, pois o cliente deve discutir alguns tipos de interações que ocorrerão na interface do usuário, etc. 13

14 APOO X AP Orientados a Funções As abstrações podem corresponder aos conceitos presentes no domínio do problema. O nível é mais natural. É mais fácil se comunicar com o usuário ou domain expert na linguagem dele. Fases de Desenvolvimento Clássico (década de 1960) 14

15 Fases de Desenvolvimento Iterativo e Incremental (1990) Cenário atual UML Histórico 15

16 O que é a UML? Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação Modelos O que é um modelo? Um modelo é uma simplificação (representação) da realidade O que modelamos? Dimensões: dados, função, comportamento 16

17 Objetivos da Modelagem Compreender melhor o sistema que estamos desenvolvendo Visualizar o sistema Documentar decisões tomadas Especificar comportamento ou a estrutura de um sistema Princípios da Modelagem A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida Cada modelo poderá ser expresso em diferentes níveis de precisão Os melhores modelos estão relacionados à realidade Nenhum modelo único é suficiente. Qualquer modelo nãotrivial será melhor investigado por meio de um pequeno conjunto de modelos quase independentes 17

18 A UML não é um processo uma metodologia análise e projeto OO regras de projeto BOOCH UML OMT Diagrama de Estados Diagrama de Objetos (Colaboração) Diagrama de Processo (Desenvolvimento) Diagrama de Módulos (Componentes) OOSE Diagrama de Estados Diagrama de Classes Use Case Subsistemas (Package) Diagrama de Interações MiniEspecificação 18

19 Origem e Evolução da UML Parceiros da UML UML 1.1 UML 1.0 UML 0.9 & 0.91 Unified Method 0.8 Industrialização (Set 97) Padronização (Jan 97) Unificação II (Out 96) Unificação I (Out 95) Booch 93 OMT-2 Outros métodos Booch 91 OMT-1 OOSE Fragmentação Algumas aplicações Sistemas de informações corporativos Serviços bancários e financeiros Sistemas Técnicos: Telecomunicações, Transportes, Defesa/espaço aéreo Vendas de varejo Sistemas de tempo real Científicos Serviços distribuídos baseados na Web 19

20 Elementos da UML Para formar um modelo conceitual da linguagem é necessário aprender três elementos principais Blocos de construção Regras que determinam como esses blocos poderão ser combinados Mecanismos comuns aplicados na UML Blocos de Construção Três tipos: Itens: são abstrações Relacionamentos: os relacionamentos reunem esses itens Diagramas: agrupam coleções interessantes de item 20

21 O você entende do diagrama abaixo? 41 Itens da UML Estruturais Comportamentais De agrupamento Anotacionais 21

22 Qual a abstração do diagrama abaixo? 43 Itens estruturais São os substantivos dos modelos. São a parte estática, representando elementos conceituais ou físicos Sete tipos: classes, interfaces, colaborações, casos de uso, classes ativas, componentes e nós Window origin size open() close() move() display() Classe orderform.java Componente Servidor Nó 22

23 Itens comportamentais Representam as partes dinâmicas dos modelos. São os verbos, representando comportamentos no tempo e no espaço Dois tipos: interação e máquina de estado exibir Mensagem Aguardando Estado Itens de agrupamento São as partes organizacionais dos modelos de UML. São os blocos em que os modelos podem ser decompostos pacotes Um pacote é um mecanismo de propósito geral para a organização de elementos em grupos Regras de negócios Pacote 23

24 Itens anotacionais Partes explicativas dos modelos UML. São comentários, incluídos para descrever, esclarecer e fazer alguma observação importante sobre qualquer elemento do modelo - notas Retornar cópia Nota Relacionamentos Dependência Associação Generalização Realização 24

25 Dependência Relacionamento semântico entre dois itens, nos quais a alteração de um (o item independente) pode afetar a semântica do outro (o item dependente) FilmClip name playon() start() stop() reset() Channel dependência Associação É um relacionamento estrutural que descreve um conjunto de ligações, em que as ligações são conexões entre objetos Pessoa +emprega +funcionario Departamento 1..* 1 associação 25

26 (Agregação) A agregação é um tipo especial de associação representando um relacionamento estrutural entre o todo e sua parte todo Empresa 1 agregação parte * Departamento Generalização É um relacionamento de especialização/generalização, nos quais os objetos dos elementos especializados (os filhos) são substituíveis por objetos do elemento generalizado (os pais) Pessoa Aluno Professor Funcionario 26

27 Realização É um relacionamento semântico entre classificadores, em que um classificador especifica um contrato que outro classificador garante executar << Interface >> Agente da Regra Regras de contabilidade realização Diagramas Apresentações gráficas de um conjunto de elementos, geralmente representadas como gráficos de vértices (itens) e arcos (relacionamentos) Tipos: classes, objetos, pacotes, casos de uso, seqüências, colaborações, estados, atividades, componentes e implantação 27

28 Diagramas de classes Diagramas de classe são a espinha dorsal da maioria dos métodos orientados a objeto, inclusive UML Descrevem a estrutura estática do sistema (entidades e relacionamentos) Diagramas de pacotes Organizam elementos do sistema em grupos relacionados a fim de minimizar a dependência entre eles 28

29 Diagramas de objetos Descrevem a estrutura estática de um sistema em um determinado momento Podem ser usados para testar a precisão dos diagramas de classe Diagramas de casos de uso Modelam a funcionalidade do sistema através de atores e casos de uso Casos de uso são serviços ou funções fornecidas pelo sistema aos seus usuários 29

30 Diagramas de seqüências Descreve as interações entre as classes através das trocas de mensagens ao logo do tempo Diagramas de colaborações Representam as interações entre objetos em termos de mensagens em seqüência Descrevem tanto a estrutura estática como o comportamento dinâmico do sistema 30

31 Diagramas de estados Descrevem o comportamento dinâmico do sistema em resposta a estímulos externos São especialmente úteis para modelar objetos reativos cujos estados são disparados por eventos específicos Diagramas de atividades Ilustram a natureza dinâmica de um sistema modelando o fluxo de controle de uma atividade para outra Uma atividade representa uma operação em uma classe do sistema que resulta na mudança do estado do sistema Tipicamente, são usados para modelar fluxo de trabalho ou processos de negócio e funcionamento interno 31

32 Diagramas de componente Descreve a organização dos componentes físicos de software Ex.: código-fonte, código em tempo de execução (binário) e executáveis Diagramas de implantação Descrevem os recursos físicos em um sistema, incluindo nós, componentes e conexões 32

33 Regras da UML Especificam o que deverá ser um modelo bem-formado Modelos bem-formados são aqueles autoconsistentes semanticamente e em harmonia com todos os modelos a ele relacionados Regras para: nome, escopo, visibilidade, integridade e execução Modelagem da arquitetura vocabulário funcionalidade comportamento desempenho escalabilidade throughput Visão de projeto Visão de processo Visão de caso de uso Visão da implementação Visão da implantação gerenciamento da configuração montagem do sistema topologia do sistema distribuição fornecimento instalação 33