Análise e Projeto de Sistemas Orientados a Objetos

Transcrição

1 Análise e Projeto de Sistemas Orientados a Objetos Marco Antônio Pereira Araújo, M.Sc. maraujo@acessa.com Organização Introdução Conceituação Desenvolvimento Orientado a Objetos UML (Unified Modeling Language) RUP (Rational Unified Process) Teste em Software Orientado a Objetos Estratégias de Persistência de Objetos Refatoração Padrões de Projeto (Design Patterns) Considerações Finais 1

2 Bibliografia BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Campus, BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar. UML Guia do Usuário. 2ª. ed. Campus, FOWLER, Martin. UML Essencial. 3ª. ed. Bookman, COCKBURN, Alistair. Escrevendo Casos de Uso Eficazes. Bookman, LARMAN, Craig. Utilizando UML e Padrões. 2ª. ed. Bookman, SCOTT, Kendal. O Processo Unificado Explicado. Bookman, Bibliografia GAMMA, Erich, et al. Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Bookman, FOWLER, Martin. Refatoração Aperfeiçoando o Projeto de Código Existente. Bookman, SINTES, Anthony. Aprenda Programação Orientada a Objetos em 21 Dias. Makron Books, BINDER, Robert. Testing Object-Oriented Systems. Addison-Wesley,

3 Introdução Histórico Origens: Linguagem SIMULA67: conceito de classe Linguagem SMALLTALK Os conceitos básicos da OO já tiveram algumas décadas para amadurecimento 3

4 Motivação Noção intuitiva: o mundo é povoado por objetos que interagem entre si Melhor mapeamento: Mundo Real x Mundo Computacional Melhoria da qualidade e produtividade Aumenta o grau de reutilização Melhoria da manutenção Melhor gerenciamento da complexidade Complexidade 4

5 Métodos Estruturados x Orientados a Objetos ESTRUTURADOS ORIENTADOS A OBJETOS DECOMPOSIÇÃO ENFOQUE DADOS E PROCEDIMENTOS TRANSIÇÃO DA ANÁLISE PARA PROJETO ESTRUTURA DO SISTEMA CICLO DE VIDA FUNCIONAL TOP-DOWN PROCEDIMENTOS NÃO ASSOCIADOS A DADOS NÃO BEM RESOLVIDO HIERARQUIA DE FUNÇÕES SEQUENCIAL OBJETO TOP-DOWN E BOTTOM-UP PROCEDIMENTOS ASSOCIADOS A DADOS NATURAL OBJETO / CLASSE HIERARQUIA DE CLASSES ITERATIVO EXECUÇÃO DO SISTEMA CHAMADA DE FUNÇÕES PASSAGEM DE MENSAGENS Conceituação 5

6 Paradigma Orientado à Objetos Conjunto de conceitos e regras que determinam como desenvolver software utilizando a tecnologia de orientação à objetos Objetos Representam elementos do mundo real Possuem Atributos (estado) Serviços (comportamento) Identidade 6

7 Atributos e Serviços Atributo É um dado (informação de estado) para o qual cada objeto em uma classe tem seu próprio valor Serviço É um comportamento específico que um objeto deve exibir Identidade Identifica de forma única um objeto, independente dos valores de seus atributos Objetos 7

8 Classe Uma descrição de um ou mais objetos com os mesmos atributos e serviços Uma classe pode ser vista como uma fábrica de objetos Objetos pertencentes à classe são ditos INSTÂNCIAS da classe Instanciação: ato de criar (instanciar) objetos de uma classe Classe 8

9 Tipos de Classes Classe Concreta Pode instanciar objetos Classe Abstrata Não pode instanciar objetos Classe e Objetos Classe Automóvel Atributos: cor, proprietário, ano, etc. Cor Proprietário Ano Classe Automóvel Serviços: acelerar, frear, abastecer, etc. Azul João 1992 Verde Maria

10 Classificação Dificuldade da Classificação 10

11 Abstração Princípio de ignorar os aspectos de um assunto não relevantes para o propósito em questão, tornando possível uma concentração maior nos assuntos principais A abstração consiste então na seleção de alguns aspectos, ignorando outros Abstração 11

12 Encapsulamento (Ocultamento de Informações) O encapsulamento proíbe a visualização interna de um objeto Atributos são associados à serviços e só podem ser acessados por estes A interface para cada módulo é definida de forma a revelar o menos possível sobre seu funcionamento interno Encapsulamento Serviços só têm acesso aos atributos da classe para a qual foram definidos Atributos de uma classe só podem ser manipulados por serviços desta classe Serviços (ou Métodos) Atributos 12

13 Encapsulamento Herança Mecanismo para expressar a similaridade entre classes, simplificando a definição de classes iguais a outras que já foram definidas Representa a estrutura Generalização e Especialização, tornando explícitos os atributos e serviços comuns em uma hierarquia de classes 13

14 Herança Herança Superclasses representam abstrações generalizadas Subclasses representam abstrações onde variáveis de instância e métodos são adicionados, modificados ou removidos Relacionamento do tipo é-um Superclasses podem possuir serviços virtuais, que podem ser redefinidos nas subclasses Superclasses podem possuir serviços abstratos, que devem ser implementados nas subclasses, não possuindo implementação na superclasse 14

15 Herança Com o mecanismo de herança, ao se criar uma classe a partir de outra classe, a nova classe (subclasse da classe original) herda todas as suas características (atributos e serviços) Dois tipos Simples Múltipla Herança Simples Subclasse herda de apenas uma superclasse Generalização Veículo Terrestre Superclasse Especialização Automóvel Subclasse 15

16 Herança Múltipla Subclasse herda de mais de uma superclasse Principal problema: conflito de nomes Generalização Veículo Terrestre Veículo Aquático Superclasse Especialização Anfíbio Subclasse Polimorfismo Possibilidade de enviar um mesmo seletor de mensagem para diferentes objetos, mesmo que estes sejam instâncias de classes diferentes Significa que a mesma operação pode atuar de modos diferentes em classes diferentes 16

17 Associação Um modelo de mapeamento de domínio que um objeto precisa ter com outros, para cumprir suas responsabilidades Tipos: 1:1 - atributo simples (objeto) em ambas as classes da associação 1:N - atributo simples (objeto) em uma das classes da associação e atributo coleção (lista) na outra classe N:N - atributo coleção (lista) em ambas as classes da associação Composição / Agregação Utilizado quando objetos de determinadas classes são utilizados em conjunto e um faz parte do outro Representa a estrutura Todo-Parte Relacionamento do tipo tem-um Composição: relacionamento mais forte Ex. Carro e Motor em Locação de Veículos Agregação: relacionamento mais fraco Ex. Carro e Motor em Ferro-Velho 17

18 Composição / Agregação Mensagens Paradigma utilizado para comunicação entre objetos A independência de objetos é enfatizada através da troca de mensagens Os dados de um objeto não podem ser manipulados ou vistos por outro objeto, ao invés disso, uma mensagem é enviada ao objeto 18

19 Mensagens Persistência Relaciona-se com a sobrevivência (armazenamento) do objeto O objeto é livre para sobreviver à morte de seu criador Objetos podem ser persistentes ou não 19

20 Persistência Construção da Aplicação 20

21 Tipificação Forte Ligação Dinâmica Objetos só existem em tempo de execução Habilidade de uma operação ser executada diferentemente de acordo com o tipo (classe) a que um objeto está associado Significa que a ligação (acoplamento) de uma mensagem com seu método correspondente é feito em tempo de execução 21

22 Reutilização O reuso é inerente ao processo de solução de problemas utilizado pelos seres humanos Na medida em que soluções são encontradas, estas são utilizadas em problemas similares A capacidade de abstração é o que garante a adaptação necessária ao novo contexto Reutilização Definições É a utilização de produtos de software desenvolvidos ao longo do ciclo de vida em uma situação diferente daquela para a qual foram originalmente produzidos É o processo de utilização de software préexistente (programas, procedimentos, documentação e dados associados) durante o desenvolvimento de um novo sistema ou componente 22

23 Reutilização Motivação Melhores índices de produtividade Produtos de melhor qualidade, mais confiáveis, consistentes e padronizados Redução dos custos e tempo envolvidos no desenvolvimento de software Maior flexibilidade na estrutura do software produzido, facilitando sua manutenção e evolução Reutilização Objetos de reutilização Código (rotinas, programas, componentes) Projeto (informações sobre o projeto, decisões de projeto, arquiteturas) Análise (requisitos, especificações, aspectos sobre o domínio da aplicação) Conhecimento (formal e informal, sobre o domínio de aplicação, sobre computação, experiência passada) Processos de desenvolvimento de software 23

24 Reutilização Objetos existentes são novamente aproveitados, com pouca ou nenhuma alteração É um benefício somente alcançado a longo prazo Somente é alcançada nos sistemas OO bem-construídos Reutilização Deve ser criada uma biblioteca de classes reutilizáveis Para que possa ser efetiva, sistemas devem ser desenvolvidos para serem reutilizados, e não apenas reutilizando objetos existentes A OO não garante a reutilização, apenas a possibilita 24

25 Reutilização Atividades do processo de reutilização Compreensão do alvo de reutilização Identificação de candidatos à reutilização Avaliação do potencial de reutilização de cada candidato e seleção do mais adequado Modificação do objeto selecionado (se necessário) Integração do objeto modificado ao processo de desenvolvimento Reutilização Construtores de Classes (Desenvolvimento para o Reuso) Utilizadores de Classes (Desenvolvimento com Reuso) 25

26 Frameworks Conjunto de classes que incorpora um projeto abstrato para uma família de problemas que se relacionam, e suporta a reutilização em uma granularidade maior que a de classes Podem ser considerados como projetos ou arquiteturas de alto nível, consistindo de classes que são especialmente projetadas para serem refinadas e usadas em grupo Framework Caixa-Branca O comportamento específico da aplicação é inserido na arquitetura genérica, somando-se métodos às subclasses de uma ou mais classes do framework. Os frameworks que fazem uso deste processo de especialização obrigam quem os utiliza a conhecer os seus dispositivos internos São mais flexíveis e permitem a sua utilização na especificação de aplicações até então desconhecidas dentro do domínio 26

27 Framework Caixa-Preta O framework recebe um conjunto de parâmetros que representa o comportamento específico da aplicação. Este fornecimento de parâmetros é feito por protocolo, através da interface de cada classe do framework e, por isso, esta forma de especialização requer que seja conhecida apenas esta interface Facilita a reutilização, pois exige que apenas a sua interface seja compreendida, podendo ser, portanto, encarado como um grande componente que encapsula o comportamento genérico de um domínio Reutilização Fatores de influência Tamanho do programa: quanto maior é o programa, maior é a chance de se tornar complexo, dificultando sua compreensão e/ou modificação, reduzindo suas possibilidades de reutilização Estrutura do programa: influi diretamente na compreensão e/ou modificação do programa. Estruturas complexas reduzem a chance de reutilização 27

28 Reutilização Linguagem de programação: bibliotecas formadas por componentes escritos em diferentes linguagens de programação. A reutilização pode implicar na conversão entre linguagens Documentação: a insuficiência de documentação interna (comentários) e externa (especificação, projeto, etc.) pode impossibilitar a reutilização Reutilização Agente da reutilização: quanto mais experiente for o agente da reutilização (na área de aplicação e em aspectos computacionais), mais facilmente ele será capaz de compreender e/ou modificar componentes, portanto, reutilizá-los Grau de generalidade: quanto mais genérico for o objeto de reutilização, maiores serão as chances de ser reutilizado 28

29 Reutilização Independência: quanto mais independente (de hardware e de software), maiores as chances de reutilização Coesão: força que mantém unidos os elementos de um objeto de reutilização. Quanto maior for a coesão, mais reutilizável será o objeto Acoplamento: grau de interdependência entre objetos. Quanto menor for o acoplamento, mais reutilizável será o objeto Tecnologias Orientadas à Objetos x Baseadas em Objetos As orientadas à objetos suportam todos os conceitos como encapsulamento, heranças nas classes e polimorfismo nas operações As baseadas em objetos apenas aderem parcialmente a estes conceitos Nem todas as ferramentas visuais são orientadas à objetos 29

30 Desenvolvimento Orientado a Objetos Processo de Desenvolvimento Define o modelo que será utilizado para o desenvolvimento do produto Normalmente, engloba Ciclo de Vida Métodos Ferramentas 30

31 Desenvolvimento OO Em geral, envolve as seguintes atividades Levantamento dos requisitos Identificação de candidatos a classes/objetos Identificação das interações entre objetos e classes Projeto Codificação Testes Ciclo de Vida A OO incentiva o desenvolvimento através de um processo incremental e interativo, com refinamento crescente do software Essa abordagem é facilitada pela utilização de um modelo homogêneo para a representação das etapas de desenvolvimento do software 31

32 Ciclo de Vida em Espiral Meta-Modelo: qualquer ciclo de vida pode ser utilizado na fase de desenvolvimento A medida que componentes são desenvolvidos Os componentes são avaliados O desenvolvimento futuro é replanejado Riscos são avaliados O ciclo termina com o produto pronto Ciclo de Vida em Espiral Planejamento Análise de Riscos Validação Desenvolvimento 32

33 Análise Orientada à Objetos OOA = Object Oriented Analysis (Análise Orientada à Objetos) Em OO, um modelo é construído utilizando classes, e não objetos do mundo real (as instâncias) Etapas Encontre as classes Identifique os relacionamentos Defina atributos Defina serviços Projeto Orientado à Objetos OOD = Object Oriented Design (Projeto Orientado à Objetos) O projeto OO utiliza as mesmas ferramentas da análise, resultando num gap semântico muito menor entre as fases de desenvolvimento de sistemas, possibilitando uma transição da análise para o projeto mais eficiente 33

34 Projeto Orientado à Objetos O projeto OO transforma as abstrações do domínio em classes implementáveis, embora nem todas as classes venham do domínio No projeto OO, basta acrescentar ao modelo de análise as classes que irão tratar da interação humana e de aspectos computacionais Projeto Orientado à Objetos Os sistemas devem ser construídos em 3 camadas, isolando os objetos de interface dos objetos de domínio, e estes da camada de acesso ao banco de dados Etapas Refine o modelo (verificar herança simples e múltipla, incluir classes para o sistema e para conjuntos de objetos, caso necessário) Projete o gerente de dados (persistência) Projete o gerente de interface Projete o(s) gerente(s) de tarefas (relatórios, consultas, estatísticas, etc.) 34

35 Programação Orientada à Objetos OOP = Object Oriented Programming (Programação Orientada à Objetos) Deixar a OO limitada à programação será extremamente limitante e de poucos ganhos quanto à produtividade É importante pensar em objetos desde a análise Principais Linguagens Puras: forçam o uso do paradigma OO Smalltalk Java Eiffel Híbridas: permitem a utilização de diferentes paradigmas C++ Object Pascal OOCobol 35

36 Métodos Orientados a Objetos Um Método de Desenvolvimento de Software é um conjunto de procedimentos técnicos e convenções notacionais para a construção organizada de produtos de software Principais Métodos Coad & Yourdon Booch Rumbaugh (OMT) Jacobson (Use case) Unified Method / UML Fusion Shlaer-Mellor 36

37 UML Unified Modeling Language UML - Definição Uma evolução das representações tradicionais para análise e projeto Unifica as formas de representação de Booch, Rumbaugh e Jacobson Adotado como padrão pela OMG (Object Management Group) 37

38 UML - Definição Normalmente é definido como uma linguagem de modelagem e não um método propriamente dito Uma proposta de processo de desenvolvimento que pode ser utilizada em conjunto é o RUP (Rational Unified Process), definido por Booch, Jacobson e Rumbaugh UML -Histórico Nov 97 UML é aprovada pelo OMG 38

39 UML - Utilização A UML pode ser utilizada para Mostrar a periferia de um sistema e suas maiores funções usando Casos de Uso e Atores Ilustrar realizações de Casos de Uso com Diagramas de Interações Representar a estrutura estática de um sistema usando Diagramas de Classes Modelar o comportamento de objetos com Diagramas de Estado Revelar a arquitetura de implementação física com Diagramas de Componentes e Distribuição Requisitos Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema Requisitos Funcionais: descrevem uma interação entre o sistema e seu ambiente Requisitos Não Funcionais (ou Restrições): descrevem uma restrição para o sistema que limita as possíveis escolhas de solução para o problema 39

40 Requisitos Uma especificação de requisitos é importante porque: Estabelece uma base de concordância entre o cliente e o fornecedor sobre o que o software fará Fornece uma referência para a validação do produto final Uma especificação de requisitos de alta qualidade é um pré-requisito para um software de alta qualidade Reduz o custo do desenvolvimento Requisitos (Padrão IEEE 830) Estrutura de um documento de requisitos Título Índice Introdução Propósito Escopo Definições Descrição Geral Visão Geral Perspectiva do Produto Funções do Produto Requisitos Requisitos Funcionais Requisitos Não Funcionais 40

41 Requisitos Funcionais - Exemplos Requisito Funcional 1: O sistema deve permitir à secretaria cadastrar cursos, contendo código, descrição, carga horária, professor coordenador, quantidade de períodos e tipo de curso (Graduação, Especialização, Mestrado e Doutorado). Requisito Funcional 2: O sistema deve permitir à secretaria cadastrar disciplinas, contendo curso, código da disciplina, descrição, período, número de aulas, ementa e bibliografia, bem como seus pré-requisitos. Requisito Funcional 3: O sistema deve permitir à secretaria cadastrar alunos contendo matrícula, nome, data de nascimento, curso, ano de início, semestre de início, e- mail, telefone residencial, telefone comercial, telefone celular, fotografia, endereço completo (logradouro, número, complemento, bairro, cidade, UF, CEP), CPF, documento de identidade (número, órgão expedidor, UF e data expedição). Requisitos Funcionais - Exemplos Requisito Funcional 4: O sistema deve permitir à secretaria cadastrar professores, contendo matrícula, nome, data de nascimento, data de admissão, , telefone residencial, telefone comercial, telefone celular, fotografia, endereço completo (logradouro, número, complemento, bairro, cidade, UF, CEP), CPF, documento de identidade (número, órgão expedidor, UF e data expedição), titulação máxima (graduação, especialização, mestrado e doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo professor. Requisito Funcional 5: O sistema deve permitir à secretaria cadastrar turmas, contendo curso, disciplina, ano, semestre, descrição da turma, número máximo de alunos, horários e professor responsável. 41

42 Requisitos Funcionais - Exemplos Requisito Funcional 6: O sistema deve permitir à secretaria matricular alunos em turmas específicas. Requisito Funcional 7: O sistema deve permitir ao professor cadastrar avaliações e freqüência de alunos de uma turma específica. Requisito Funcional 8: O sistema deve calcular a aprovação de alunos, considerando 75% de freqüência mínima. Além disso, média menor do que 3 (três), implica em reprovação, média maior ou igual a 3 (três) e menor que 7 (sete) implica em prova final e média igual ou superior à 7 (sete) implica em aprovação. Para a prova final, a média desta nota com a média anterior menor ou igual a 5 (cinco) implica em reprovação, caso contrário, em aprovação. Requisitos Funcionais - Exemplos Requisito Funcional 9: O sistema deve permitir ao professor a emissão da relação de alunos por turmas, contendo descrição do curso, nome da disciplina, ano, semestre, turma, nome do professor, matrícula do aluno e nome do aluno. Requisito Funcional 10: O sistema deve permitir à secretaria a emissão da relação de disciplinas por curso, contendo nome do curso, nome das disciplinas, total de disciplinas por curso e total de todas as disciplinas. Requisito Funcional 11: O sistema deve permitir à secretaria a emissão do histórico escolar, contendo matrícula do aluno, nome do aluno, ano, semestre, nome das disciplinas, número de aulas, número de faltas e avaliações. 42

43 Requisitos Não Funcionais - Exemplos Requisito não funcional 1: O sistema deve possibilitar que todos os relatórios sejam pré-visualizados antes do envio para a impressora. Requisito não funcional 2: O sistema deve apresentar o recurso de ajuda on-line sensível ao contexto. Requisito não funcional 3: O sistema deve processar matrículas em, no máximo, 5 segundos UML - Use Cases Tipicamente representa uma interação entre um usuário e um sistema computacional Pode ser utilizado para capturar os contextos de utilização do sistema Tem a capacidade de representar os requisitos do sistema em alto nível de abstração É um padrão de comportamento que o sistema exibe Apresenta uma visão externa do sistema 43

44 UML - Use Cases Elementos que compõem um diagrama de use cases Ator: representa um papel que um usuário desempenha com respeito ao sistema Situação (use case): representa as funcionalidades externas do sistema Extensões: representam extensões à situações pré-definidas Usos: demonstram a reutilização de situações pré-definidas UML - Use Cases Atores Um Ator é alguém ou alguma coisa que deve interagir com o sistema a ser desenvolvido Cada caso de uso é uma seqüência de transações relacionadas executadas por um ator e o sistema, em um diálogo Secretaria Professor Aluno Sistema Faturamento 44

45 UML - Use Cases Atores são examinados para determinar suas necessidades Coordenador: manter o currículo Professor: solicitar lista de cursos Aluno: efetuar matrícula Sistema Cobrança: recebe informações sobre cobranças Cadastrar Aluno Emitir Histórico Escolar Efetuar Matrícula UML - Use Cases Diagramas de use case são criados para se visualizar a relação entre atores e casos de uso Cadastrar Aluno Secretaria Secretaria Emitir Histórico Escolar Aluno Efetuar Matrícula Secretaria 45

46 UML - Use Cases À medida em que casos de uso são documentados, outras relações entre casos de uso poderão ser descobertas Uma relação de uso (use) mostra comportamento que é comum a a um ou mais casos de uso Uma relação de extensão (extend) mostra comportamento opcional Efetuar Matrícula <<use>> <<use>> Validar Senha Emitir Histórico Escolar UML - Use Cases Secretaria Efetuar Matrícula <<extend>> Emitir Declaração Matrícula 46

47 Diagrama de Casos de Uso UML- Especificação de Casos de Uso Caso de Uso Super Caso de Uso Sumário Ator Principal Atores Secundários Pré-Condições Curso Normal Cursos Alternativos Cursos de Exceção Pós-Condições Requisitos Não Funcionais Requisitos de Interface com o Usuário Regras do Negócio 47

48 UML- Especificação de Casos de Uso Caso de Uso: Matricular Aluno Super Caso de Uso: Não de aplica Sumário: Este caso de uso é iniciado pela secretaria quando da matrícula de um aluno em uma turma de uma determinada disciplina. Ator Principal: Secretaria Ator Secundário: Não se aplica Pré-Condições: Usuário da secretaria logado no sistema UML- Especificação de Casos de Uso Curso Normal: 1. Secretaria solicita ao sistema a matrícula de alunos; 2. Sistema exibe uma lista com as turmas cadastradas, contendo descrição do curso, descrição da disciplina, ano, semestre e descrição da turma; 3. Sistema solicita a opção de matricular alunos a partir da seleção de uma turma na lista de turmas disponibilizada; 4. Secretaria seleciona uma turma; 5. Sistema exibe a lista de alunos matriculados na turma, professor responsável, total de vagas e vagas restantes; 6. Sistema solicita o número de matrícula do aluno; 7. Secretaria informa o número de matrícula do aluno; 8. Sistema solicita confirmação da matrícula; 9. Secretaria confirma os dados; 10. Sistema efetua validação da matrícula (RN1) (RN2) (RN3); 11. Sistema armazena a matrícula; 12. Sistema fecha a interface. 48

49 UML- Especificação de Casos de Uso Cursos Alternativos: a) Cancelamento da operação de matrícula Entre os passos 1 e 8, a Secretaria pode cancelar a operação de matrícula, fechando a interface; Cursos de Exceção: a) A turma está com o número total de vagas preenchidas Sistema avisa que a matrícula não poderá ser efetuada e o caso de uso se encerra; b) O aluno não é do curso da turma selecionada Sistema avisa que a matrícula não poderá ser efetuada e o caso de uso se encerra; c) O aluno não está na situação de matriculado Sistema avisa que a matrícula não poderá ser efetuada e o caso de uso se encerra; UML- Especificação de Casos de Uso Pós-Condições: Podem ser lançadas avaliações para este aluno nesta turma Requisitos Não Funcionais: Não se aplica Requisitos de Interface com o Usuário: O sistema deve fornecer uma interface gráfica com facilidades para pesquisa de turmas através de nomes de cursos e nomes de disciplinas. Regras do Negócio: RN 1: Um aluno só pode se matricular em disciplinas que tenha obtido aprovação em seus pré-requisitos RN 2: Um aluno não pode matricular-se em turmas com coincidência de horários RN 3: Não podem ser matriculados alunos além do limite de vagas da turma 49

50 UML - Diagrama de Classes Descreve os tipos dos objetos existentes no sistema e as associações estáticas entre eles As principais relações estáticas são Classes, suas estruturas internas e comportamento Associações, composições, agregações, dependências, e relações de herança Multiplicidade e indicadores de navegação Nomes de papéis (o que uma classe representa para outra) Mostram também os atributos, operações e restrições que se aplicam aos objetos de uma determinada classe UML - Diagrama de Classes Classes Representam os tipos de objetos existentes no modelo Descritas a partir de seus atributos, operações e restrições Podem ser organizadas segundo uma estrutura de generalização/especialização Admitem classificação simples ou múltipla (herança simples ou múltipla) Nome da classe em itálico representa classe abstrata Classe Atributos Operações( ) 50

51 UML- Herança Herança é uma relação entre uma super-classe e suas sub-classes Atributos comuns, operações, relações e/ou, são mostradas no nível aplicável mais alto da hierarquia Generalização Especialização 1 Especialização 2 UML - Diagrama de Classes Associações Representam relacionamentos entre instâncias de classes (um aluno se matricula em um curso, um curso possui várias disciplinas) Conceitualmente representam relacionamentos entre classes Possuem 2 papéis, um para cada sentido da associação, que pode ser explicitamente Associação representado por um label Classe 1 Classe 2 min..max min..max 51

52 UML - Diagrama de Classes Associação Multiplicidade define como muitos objetos participam numa relação Multiplicidade é o número de instâncias de uma classe que se relacionam a UMA instância de uma outra classe Para cada associação e agregação, haverá duas decisões relativas a multiplicidade a se tomar: uma para cada lado da relação UML - Diagrama de Classes Associações A multiplicidade de um papel representa o número de objetos que pode participar da associação Do ponto de vista da especificação do sistema as associações representam responsabilidades Do ponto de vista de implementação associações indicam a existência de referências entre os objetos, e servem para indicar a navegabilidade do modelo 52

53 UML - Diagrama de Classes Multiplicidade de Associações 1 Exatamente um 1..* 1 ou mais Classe Classe Classe * Muitos (0 ou mais) Classe 1-3,5 Possibilidades específicas Classe 0..1 Opcional (0 ou 1) Curso código * Contêm É-composto-de 1..* Está-incluída Disciplina código UML - Diagrama de Classes Associação Relações fornecem um caminho para a comunicação entre os objetos Diagramas de sequência e/ou comunicação podem identificar ligações entre objetos para se chegar ao comportamento desejado Tipos de relações Associação Agregação Composição Dependência 53

54 UML - Diagrama de Classes Associação Uma associação é uma conexão bi-direcional entre classes Uma associação é mostrada como uma linha conectando as classes relacionadas Uma agregação é um tipo mais forte de conexão, onde a relação é entre o todo e suas partes Uma agregação é mostrada como uma linha conectando as classes relacionadas com um losango perto da classes que representa o todo UML - Diagrama de Classes Associação Uma relação de dependência é uma forma mais fraca de relação, mostrando uma relação entre um cliente e um fornecedor, onde o cliente não tem conhecimento semântico do fornecedor Uma dependência é mostrada como uma linha pontilhada entre o cliente e o fornecedor 54

55 UML - Diagrama de Classes Associações Classe 1 Associação Classe 2 Todo Agregação Parte min..max min..max min..max min..max Classe A Classe B Todo Composição Parte min..max min..max Classe Associativa Classe B Anotação Classe 1 min..max min..max Navegabilidade Classe 2 min..max min..max Dependência Classe 1 Classe 2 UML - Diagrama de Classes 55

56 UML - Diagrama de Classes Associação Apesar de associações e agregações serem bidirecionais por definição, frequentemente é desejável restringir a navegação em uma única direção Caso a navegação seja restringida, uma seta é adicionada para se indicar a direção da navegação Muitas vezes é conveniente definir a navegabilidade a partir dos diagramas de seqüência UML - Diagrama de Classes A estrutura de uma classe é representada pelos seus atributos O comportamento de uma classe é representado pelas suas operações Atributos podem ser encontrados pelo exame das definições de classes, requisitos de problemas, e pela aplicação do conhecimento do domínio Cada Disciplina oferecida possui uma ementa e uma bibliografia Disciplina Ementa Bibliografia 56

57 UML - Diagrama de Classes UML Especificação de Classes Atributos Nome Descrição Tipo (Integer, Real, Boolean, Character, Classe) Tamanho Visibilidade Obrigatoriedade Restrições 57

58 UML Especificação de Classes Serviços Nome Descrição Tipo (Procedimento / Função) Parâmetros (Opcional) Nome Tipo Tamanho Obrigatoriedade Tipo de Saída (para Funções) UML Diagramas de Interação Diagramas de Interação descrevem como casos de uso são realizados como interações entre associações de objetos 58

59 UML Diagramas de Interação Diagrama de Interação Modelos que descrevem como grupos de objetos colaboram para obter algum comportamento Tipicamente um diagrama de interação captura o comportamento de um único caso de uso Há dois tipos de Diagramas de Interação Diagramas de Seqüência Diagramas de Comunicação UML - Diagrama de Seqüência Um Diagrama de Seqüência mostra interações de objetos ordenados numa seqüência de tempo Operações podem ser encontradas examinando-se os Diagramas de Interação Relacionamentos podem ser descobertos examinando-se os Diagramas de Interação 59

60 Diagrama de classes após a construção do diagrama de seqüência 60

61 UML Diagrama de Comunicação Um Diagrama de Comunicação mostra interações organizadas à volta de objetos e as ligações de um para o outro 61

62 UML Diagrama de Estados Mostra os estados de uma determinada classe, os eventos que causam a transição de um estado para outro e as ações resultantes da troca de estados Representa a visão do modelo dinâmico de uma simples classe ou do sistema como um todo Diagramas de Estados são criados para objetos que tenham um comportamento dinâmico significante UML Diagrama de Estados Estados Representam os resultados acumulativos do comportamento de um objeto Transições (eventos) Alguma ocorrência que pode causar a troca do estado de um sistema 62

63 UML Diagrama de Estados Matriculado Formado Trancado Abandono UML Diagrama de Estados Notação Avançada Ações dos Estados Ações podem ser associadas a estados Transição Condicional Transições somente ocorrerão se satisfizerem a determinadas condições Estados aninhados Estados podem ser particionados 63

64 UML Diagrama de Estados Iniciar Ação fazer: iniciar curso Cancelar Incluir Aluno / Contador = 0 Cancelar Inclui aluno[ contador < 10 ] Abrir entrar: Matricular Aluno Sair: incrementa contador [ contador = 10 ] Cancelado fazer: Notificar Aluno Matriculado Cancelar Fechado fazer: Finalize curso UML Diagrama de Atividades Utilizados para modelar o fluxo de atividades em um procedimento Decisões podem ser representadas quando mais de um evento pode ocorrer em uma atividade Atividades são equivalentes aos estados Eventos são equivalentes às transições Normalmente são associados a diagramas de estados 64

65 UML Diagrama de Atividades Um Diagrama de Atividades pode ser usado com diferentes propósitos, incluindo Capturar o trabalho que será executado quando uma operação é disparada (ações) Capturar o trabalho interno em um objeto Mostrar como um grupo de ações relacionadas pode ser executadas, e como vão afetar outros objetos Mostrar como uma instância de caso de uso pode ser executada em termos de ações e objetos UML Diagrama de Atividades Atividade A Transição Atividade B Início Atividade inicial Atividade X Fim Atividade B Atividade C Decisão Saída B Atividade D Saída A A barra indica que uma atividade despacha para várias que ocorrem em paralelo ou em ordem não previsível 65

66 UML Diagrama de Atividades Matricular Aluno Cancelar matrícula [para cada pré requisito da disciplina] negado Verificar Horários [ok] [Horários e Pré-Requistos OK] Verificar Pré-Requisitos [ok] Aceitar matrícula UML Diagrama de Empacotamento Representa as classes e seus relacionamentos Mostra uma visão da estrutura de classes do sistema Indicam os papéis e responsabilidades das entidades que provêem o comportamento do sistema 66

67 UML Diagrama de Empacotamento Interface do Usuário Objetos do Sistema Utilidades Banco de Dados UML Diagrama de Empacotamento Academico Faturamento Aluno Aluno (from Acadêmico) Mensalidade 67

68 UML Diagrama de Componentes Diagramas de Componentes ilustram a organização e dependências entre componentes de software Um componente pode ser Um componente de código fonte Um componente de run-time, ou Um componente executável UML Diagrama de Componentes Cobrança.exe Sistema Cobrança Registro.exe curso.dll curso pessoas.dll Usuário Aluno Professor Curso Disciplina 68

69 UML Diagrama de Desenvolvimento Apresenta os relacionamentos físicos entre os componentes de software e hardware que compõem o sistema É bastante útil para apresentar a distribuição dos componentes no sistema Os nós do diagrama representam algum tipo de unidade computacional Conexões entre os nós mostram algum tipo de comunicação Componentes representam módulos físicos (código) As dependências entre os componentes devem ser as mesmas que as existentes entre os pacotes UML Diagrama de Desenvolvimento ClienteA : Pentium 200 <<TCP/IP>> ClienteB : Pentium 200 <<TCP/IP>> Servidor de Aplicação SQL <<TCP/IP>> Servidor de Banco de Dados : ORACLE 8 69

70 UML Diagrama de Distribuição O Diagrama de Distribuição mostra a configuração dos elementos de processamento run-time e dos processos que rodam dentro deles O Diagrama de Distribuição visualiza a distribuição dos componentes através de toda a empresa UML Diagrama de Distribuição Matrícula Database Biblioteca Sede Principal Salas 70

71 Ferramentas CASE Rational Rose Visual Paradigm Argo UML Poseidon Jude System Architect RUP Rational Unified Process 71

72 RUP Definição RUP é um framework genérico de um processo de desenvolvimento RUP é baseado em componentes RUP utiliza toda a definição da UML RUP é dirigido pelos use cases, centrado na arquitetura, iterativo e incremental (conceitos-chave) RUP Definição Conjunto de atividades bem definidas com responsáveis com artefatos de entrada e saída com dependências entre as mesmas e ordem de execução com modelo de ciclo de vida descrição sistemática de como devem ser realizadas 72

73 RUP Características Principais O desenvolvimento de sistemas seguindo o RUP é Iterativo e incremental Guiado por casos de uso (use cases) Baseado na arquitetura do sistema RUP Fases O ciclo de vida de um sistema consiste de quatro fases, divididas em iterações Concepção Elaboração Construção Transição Tempo Marco do Objetivo (no Ciclo de Vida) Marco da Arquitetura (no Ciclo de Vida) Marco Capacidade Inicial de Operação Concepção (define o escopo do projeto) Elaboração (define os requisitos e a arquitetura) Construção (desenvolve o sistema) Transição (implanta o sistema) Marco da Liberação do Produto 73

74 RUP Concepção Responder às seguintes perguntas Quais serão as principais funcionalidades do sistema? Em linhas gerais, como será a arquitetura do sistema? Qual é a estimativa inicial de tempo e custo para o projeto? Quais são os principais riscos? Entendimento geral do problema e da tecnologia envolvida Estabelecer o escopo do projeto Garantir o financiamento do projeto Verificar a viabilidade do projeto RUP Elaboração Detalhamento dos requisitos do sistema Protótipo Descartável Interface com Usuário Garantir uma arquitetura estável e testada para a Construção (evitar surpresas técnicas durante a Construção) Minimizar os riscos relacionados à fase de construção Plano de desenvolvimento para as próximas fases Estimativa realista de custo e prazo para a Construção 74

75 RUP Construção Construção do produto em uma sequência de iterações Ênfase em Projeto Detalhado, Implementação e Testes Construção em incrementos sucessivos Gerar o software propriamente dito Manuais / Documentação do usuário Produto ao final da Construção ainda pode conter erros, que serão descobertos e removidos na fase de Transição RUP Transição Fazer a transição do produto para a comunidade de usuários Foco na correção de problemas e não em adição de novas funcionalidades Modificações em função de feedback dos usuários Otimização Treinamento dos usuários Montagem da estrutura de suporte Teste beta Aceitação final 75

76 RUP Iterativo e Incremental Cada iteração é planejada realiza uma seqüência de atividades (de elicitação de requisitos, análise e projeto, implementação, etc.) distintas geralmente resulta em uma versão executável do sistema é avaliada segundo critérios de sucesso previamente definidos RUP Fluxos de Trabalho Modelagem de Negócio Definição dos Processos e Modelo de Domínio Requisitos Casos de Uso + Protótipo Interface com Usuário + Glossário Análise e Projeto Desenvolvimento baseado em componentes. Mecanismos de colaboração entre componentes de forma a realizar os cenários dos casos de uso Implementação Produção de código e testes de unidade Testes Testes do sistema, baseados nos casos de uso e demais requisitos 76

77 RUP RUP Guiado por Casos de Uso Os casos de uso não servem apenas para definir os requisitos do sistema Várias atividades do RUP são guiadas pelos casos de uso: planejamento das iterações criação e validação do modelo de projeto planejamento da integração do sistema definição dos casos de teste 77

78 RUP Baseado na Arquitetura Arquitetura visão geral do sistema em termos dos seus subsistemas e como estes se relacionam A arquitetura é prototipada e definida logo nas primeiras iterações O desenvolvimento consiste em complementar a arquitetura A arquitetura serve para definir a organização da equipe de desenvolvimento e identificar oportunidades de reuso 78