análise e projeto de sistemas orientados a objetos · 2 prof. marco antônio pereira araújo,...

1

Análise e Projeto de Sistemas Orientados a

Objetos

Marco Antônio Pereira Araújo, [email protected]

Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos

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

2


Bibliografia� BEZERRA, Eduardo. Princípios de Análise e Projeto de

Sistemas com UML. Campus, 2002.� BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar.

UML – Guia do Usuário. 2ª. ed. Campus, 2006. � FOWLER, Martin. UML Essencial. 3ª. ed. Bookman,

2005.� COCKBURN, Alistair. Escrevendo Casos de Uso

Eficazes. Bookman, 2005.� LARMAN, Craig. Utilizando UML e Padrões. 2ª. ed.

Bookman, 2004.� SCOTT, Kendal. O Processo Unificado Explicado.

Bookman, 2003.


Bibliografia� GAMMA, Erich, et al. Padrões de Projeto – Soluções

Reutilizáveis de Software Orientado a Objetos. Bookman, 2000.

� FOWLER, Martin. Refatoração – Aperfeiçoando o Projeto de Código Existente. Bookman, 2004.

� SINTES, Anthony. Aprenda Programação Orientada a Objetos em 21 Dias. Makron Books, 2002.

� BINDER, Robert. Testing Object-Oriented Systems. Addison-Wesley, 1999.

� http://www.rational.com/uml� http://www.cetus-links.org� http://www.mundooo.com.br

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

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

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

EXECUÇÃO DO SISTEMA

NÃO BEM RESOLVIDO

HIERARQUIA DE FUNÇÕES

SEQUENCIAL

CHAMADA DE FUNÇÕES

OBJETO

TOP-DOWN E BOTTOM-UP

PROCEDIMENTOS ASSOCIADOS A DADOS

NATURAL OBJETO / CLASSE

HIERARQUIA DE CLASSES

ITERATIVO

PASSAGEM DE MENSAGENS

PROCEDIMENTOS NÃO ASSOCIADOS A DADOS

Conceituação

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

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

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

9


Tipos de Classes

� Classe Concreta�Pode instanciar objetos

� Classe Abstrata�Não pode instanciar objetos


CorProprietário

Ano

VerdeMaria1995

AzulJoão1992

Classe e ObjetosClasse Automóvel

Atributos: cor, proprietário, ano,

etc.

Classe Automóvel

Serviços: acelerar, frear, abastecer,

etc.

10


Classificação


Dificuldade da Classificação

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

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

Atributos

Serviços (ou Métodos)

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

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

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 Superclasse

Especialização Subclasse

Veículo Terrestre

Automóvel

16


Herança Múltipla� Subclasse herda de mais de uma

superclasse�Principal problema: conflito de nomes

Veículo Terrestre

Anfíbio

Generalização Superclasse

Especialização Subclasse

Veículo Aquático


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

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

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

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

20


Persistência


Construção da Aplicação

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

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

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

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

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)

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

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

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

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

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

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

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

PlanejamentoAnálise

de Riscos

DesenvolvimentoValidação

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

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.)

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

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

37

UMLUnified 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)

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óricoNov ‘97 UML é aprovada pelo OMG

39


� 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

UML - Utilizaçã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

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

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, 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), 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.

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.

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

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


� 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

Aluno

Secretaria

Professor

Sistema Faturamento

UML - Use Cases

45


� 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

Efetuar MatrículaCadastrar Aluno Emitir Histórico Escolar

UML - Use Cases


� Diagramas de use case são criados para se visualizar a relação entre atores e casos de uso

Secretaria

Secretaria

Secretaria

Emitir Histórico Escolar

Efetuar Matrícula

Cadastrar Aluno

Aluno

UML - Use Cases

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 opcionalEfetuar Matrícula

<<use>>

Validar Senha<<use>>

Emitir Histórico Escolar


UML - Use Cases

Secretaria

Emitir Declaração Matrícula

Efetuar Matrícula

<<extend>>

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

48


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.


49


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 selecionadaSistema 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 matriculadoSistema avisa que a matrícula não poderá ser efetuada e o caso de uso se encerra;



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é-requisitosRN 2: Um aluno não pode matricular-se em turmas com coincidência de horáriosRN 3: Não podem ser matriculados alunos além do limite de vagas da turma


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 simplesou múltipla (herança simples ou múltipla)

� Nome da classe em itálico representa classe abstrata

ClasseAtributos

Operações( )

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

Es pec ialização 1 Es pecializaçã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 representado por um label Associação

Classe 2 Classe 1

min..max min..max

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



� 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

53


UML - Diagrama de Classes

� Multiplicidade de Associações

ClasseClasse* Muitos (0 ou mais)

ClasseClasseExatamente um 1..* 1 ou mais

1-3,5 Possibilidades específicas

Classe0..1 Opcional (0 ou 1)

Curso Disciplinacódigo código

Contêm

É-composto-de

1..**

Está-incluída

1


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

54


� 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

55



Classe A Classe B

Classe Associativa

min..max min..max

Agregação

min..max min..max

ParteTodo

DependênciaClasse 1 Classe 2

ComposiçãoTodo Parte

min..max min..max

AssociaçãoClasse 2 Classe 1

min..max min..max

Anotação

Classe B

NavegabilidadeClasse 2 Classe 1

min..max min..max



56



� Apesar de associações e agregações serem bi-direcionais 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 oferecidapossui uma ementa e umabibliografia

DisciplinaEmentaBibliografia

57




UML – Especificação de Classes

� Atributos� Nome� Descrição� Tipo (Integer, Real, Boolean, Character, Classe)� Tamanho� Visibilidade� Obrigatoriedade� Restrições

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)


� Diagramas de Interação descrevem como casos de uso são realizados como interações entre associações de objetos

UMLDiagramas de Interação

59


UMLDiagramas 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


� 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

UML - Diagrama de Seqüência

60



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

61


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

UMLDiagrama de Comunicação


62


UMLDiagrama 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


UMLDiagrama 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

63


UMLDiagrama de Estados

Matriculado

Trancado

Formado

Abandono


UMLDiagrama 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

64


UMLDiagrama de Estados

Iniciar Ação Abrirentrar: Matricular Aluno

Sair: incrementa contador

Fechado

Cancelado

fazer: iniciar curso

fazer: Finalize curso

fazer: Notificar Aluno Matriculado

Incluir Aluno / Contador = 0

Inclui aluno[ contador < 10 ]

[ contador = 10 ]

Cancelar

Cancelar

Cancelar


UMLDiagrama 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

65


UMLDiagrama 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



Atividade A Atividade B

Início Atividade inicial Atividade X Fim

Transição

Atividade B

Atividade C Atividade D

Decisão Saída A

Saída B A barra indica que uma atividade despacha para várias que ocorrem em paralelo ou em ordem não previsível

66



Matricular Aluno

Cancelar matrícula

Verificar Horários Verificar Pré-Requisitos

Aceitar matrícula

[Horários e Pré-Requistos OK]

[para cada pré requisito da disciplina]

negado [ok] [ok]


UMLDiagrama 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

67


UMLDiagrama de Empacotamento

Interface doUsuário

Objetos doSistema

Banco de Dados

Utilidades


UMLDiagrama de Empacotamento

Academico Faturamento

Aluno(from Acadêmico)

Mensalidade

Aluno

68


UMLDiagrama 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


UMLDiagrama de Componentes

Curso Disciplina

Aluno Professor

curso.dll

pessoas.dll

curso

Usuário

Registro.exeCobrança.exe

SistemaCobrança

69


UMLDiagrama 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


UMLDiagrama de Desenvolvimento

<<TCP/IP>>

<<TCP/IP>>

SQL <<TCP/IP>>

ClienteA :Pentium 200

ClienteB :Pentium 200

Servidor deAplicação

Servidor deBanco deDados :

ORACLE 8

70


UMLDiagrama 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


UMLDiagrama de Distribuição

Matrícula Database

Biblioteca

Salas

SedePrincipal

71


Ferramentas CASE

� Rational Rose� Visual Paradigm� Argo UML� Poseidon� Jude� System Architect

RUPRational Unified Process

72


RUPDefiniçã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)


RUPDefiniçã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

73


RUPCaracterísticas Principais� O desenvolvimento de sistemas seguindo

o RUP é� Iterativo e incremental�Guiado por casos de uso (use cases)�Baseado na arquitetura do sistema


RUPFases

� O ciclo de vida de um sistema consiste de quatro fases, divididas em iterações

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)

Tempo

Concepção Elaboração Construção Transição

Marco doObjetivo

(no Ciclo de Vida)

Marco daArquitetura

(no Ciclo de Vida)

Marco Capacidade Inicialde Operação

Marco daLiberaçãodo Produto

74


RUPConcepçã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


RUPElaboraçã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

75


RUPConstruçã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


RUPTransiçã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

76


RUPIterativo 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


RUPFluxos 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

77


RUP


RUPGuiado 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

78


RUPBaseado 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

análise e projeto de sistemas orientados a objetos · 2 prof. marco antônio pereira araújo,...

Documents