2. PRECURSORES Object Modeling Technique - OMT de J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy e W. Lorensen (TMO - Técnica de Modelagem de Objetos), 1991 Objectology - A Use-Case Driven Approach de I. Jacobson, M. Ericsson e A. Jacobson, 1992 Object Oriented Analysis and Design - OOA & OOD de G. Booch, 1994
3.
4. P4 = Pessoa, Projeto, Produto, Processo PESSOAS financiam, escolhem, desenvolvem, gerenciam, testam, usam e são beneficiadas por produtos PROJETOS sofrem alterações. Determinam os tipos de pessoas que irão trabalhar no projeto e os artefatos que serão usados Sistema-i Sistema-i+1 ciclo fase iteração
5. P4 = Pessoa, Projeto, Produto, Processo PRODUTO código fonte, código de máquina, subsistemas, classes, diagramas: interação, de estados e outros artefatos ARTEFATO é qualquer tipo de informação criada por uma pessoa (diagramas UML, textos, modelos de interfaces) PROCESSO define quem faz o que, quando e como PU é um processo. Considera fatores organizacionais , do domínio , ciclo de vida e técnicos
6. Modelos REQUISITOS - funcionais e não-funcionais descrevem o sistema a ser desenvolvido, sob um certo ponto-de-vista, e seu ambiente, ou seja, os atores ANÁLISE classes e responsabilidades PROJETO classes de projeto, subsistemas, interfaces IMPLEMENTAÇÃO código fonte (DLLs, JavaBeams, ActiveX) TESTE casos de teste (baseado nos use-cases ) DISTRIBUIÇÃO nós físicos e os componentes em cada nó
7. Dirigido a Use-Cases Um ator é uma pessoa ou outro sistema Cada use-case é um requisito funcional do sistema Modelo Use-Case = use-cases = funcionalidade do sistema Os Use-Cases acompanham todo o processo de desenvolvimento: Especificação de Requisitos, Análise, Projeto, Implementação e Testes Cada use-case representa uma sequência de ações que produzem um resultado de utilidade para um ator
8.
9. Dirigido a Use-Cases Classe de fronteira Classe de controle Classe de entidades Modelo USE-CASE Modelo ANÁLISE Modelo PROJETO Classe Modelo IMPLEMENT <executável> <arquivo> <arquivo> relacionamento
10.
11.
12. Centrado na arquitetura Use-Cases Plataforma de software Disponibilidade de blocos reusáveis Sistemas existentes Hardware existente Requisitos não-funcionais (performance, segurança) Arquitetura influem
20. EXEMPLO Desenvolver um sistema de controle de vendedores ambulantes de um empresa. A empresa dividiu cada cidade em que atua em regiões. Cada região é controlada por um supervisor ao qual está subordinado um certo número de vendedores. A empresa possui diversos pontos distribuídos na cidade. Todo dia os vendedores passam pela empresa, de manhã, e registram, em um boletim de controle, a hora da partida, o roteiro de visitas planejado e o número de contratos de vendas que levaram. Ao final da tarde, cada vendedor passa por um pontos, e registra o resultado das atividades do dia, ou seja, os contratos de venda fechados. Até as 20 horas, todos vendedores devem ter registrados suas produções do dia. Cada ponto da empresa, processa a esta hora, um resumo das atividades registradas e o remete para a central da empresa. No outro dia o supervisor analisa os boletins recebidos e passa-os, com alguns comentários, ao controle geral de vendas da empresa. O supervisor, além de controlar a produção dos vendedores, registra o recebimento de novos vendedores e a liberação deles para o departamento pessoal que, por sua vez, controla a contratação, alocação, relocação e demissão de vendedores e supervisores.
21. Modelos Requisitos ARTEFATOS Análise Projeto Implementação Testes ARTÍFICES PASSOS e ATIVIDADES produz produzido-por composto-por
37. Análise Os requisitos externos são transformados em um modelo interno preciso e completo para desenvolver o projeto do sistema Deve ser preciso e inambíguo Pode conter redundâncias, inconsistências, etc. Usado para o desenvolvedor entender o sistema Usado para o contrato com o cliente Descreve como realizar a funcionalidade Captura a funcionalidade do sistema Estruturado por classes Estruturado por use-cases Visão interna do sistema Visão externa do sistema Linguagem do desenvolvedor linguagem do usuário MODELO DA ANÁLISE MODELO USE-CASE
38. Análise - artefatos 2. CLASSE DE ANÁLISE Classe de fronteira Classe de controle Classe de entidades EXEMPLO Interface de registro processar resumo do dia Boletim de controle 1. MODELO DA ANÁLISE
57. Projeto - artefatos 7. MODELO DE DISTRIBUIÇÃO (Diagrama de nós e conexões) 5. INTERFACE ( separa funcionalidade de implementação) 6. ARQUITETURA (VISÃO DO PROJETO) (1. Subsistemas, interfaces e dependências 2. Classes chave, classes ativas 3. Realização de use-cases centrais ao sistema 4. SUBSISTEMA DE PROJETO (pacotes de análise, componentes, produtos de software, sistemas existentes) - SUBSISTEMAS DE SERVIÇO 8. ARQUITETURA (VISÃO DO MODELO DE DISTRIBUIÇÃO)
58.
59. Projeto - passos Projeto de um use-case Projeto de uma classe Projeto de um subsistema Projeto da arquitetura ARQUITETO ESPECIFICADOR DE COMPONENTES ESPECIFICADOR DE USE-CASES
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70. Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO 2. COMPONENTE 3. SUBSISTEMA DE IMPLEMENTAÇÃO 4. INTERFACE 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO
78. Projeto - passos Integrar sistemas Implementar uma classe Implementar um subsistema Implementação arquitetural ARQUITETO ENGENHEIRO DE COMPONENTES INTEGRADOR DE SISTEMAS Teste de unidade