1.
Análise Orientada a Objetos<br />Prof. Eliseu Castelo Branco Jr.,PMP,MSc.<br />ecastelob@gmail.com<br />

2.
Conceitos de Orientação a Objetos<br />Visão Geral da UML<br />Diagrama de Caso de Uso<br />Diagrama de Classes<br />Diagrama de Objetos<br />Diagramas de Interação<br />Diagrama de Estado<br />Diagrama de Atividades<br />Diagramas de Implementação<br />Ementa da Disciplina<br />

3.
Cronograma de Aulas<br />

4.
Provas sobre conteúdo teórico da disciplina (Av1, Av2, Av3)<br />Trabalhos de pesquisa publicados na Internet<br />Documentos de Análise e Projeto de software entregues<br />Exercícios realizados em sala de aula<br />OBS: mínimo de 75% de presença em sala de aula necessário para aprovação na disciplina.<br />Avaliações<br />

5.
Sistemas de software são complexos.<br />O uso de modelos auxilia na compreensão de conceitos complexos.<br />Introdução<br />

6.
O desenvolvimento de um sistema envolve grande quantidade de atividades e pessoas<br />Erros são inevitáveis e se identificados nos modelos sua correção é mais fácil e barata.<br />Introdução<br />

7.
O uso de modelos reduz o custo do desenvolvimento de sistemas.<br />O modelo permite prever o comportamento do sistema no futuro.<br />Introdução<br />

8.
A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares.<br />O que é modelagem de software?<br />

9.
“Paradigma é a forma de abordar um problema”<br />Princípios:<br />Qualquer coisa é um objeto<br />Objetos realizam tarefas através da requisição de serviços a outros objetos<br />Cada objeto pertence a uma classe<br />A classe é um repositório para comportamento associado ao objeto<br />Classes são organizadas em hierarquias<br />Paradigma da Orientação a Objetos<br />

10.
O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados OBJETOS. Cada objeto realiza tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada.<br />Paradigma da Orientação a Objetos<br />

11.
Tipos de Sistemas<br />

12.
O Sistema contem subsistemas<br />

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.
Subsistemas de um Sistema de Informação<br />

29.
Módulos do Sistema (subsistemas)<br />

30.
Classe Movimentação Financeira<br />Classe Bancos<br />Classe Rendas Diversas <br />Classe Contas a Pagar<br />Classe Receitas Diversas<br />Subsistema Contas a Pagar<br />

31.
Classe Banco<br />Atributos<br />Métodos<br />

32.
O que é Análise e Projeto?<br />Análise — “o quê”<br />Investigação do problema e dos requisitos<br />Projeto — “como”<br />Descrição de uma solução lógica<br />Requisitos<br />Casos de uso<br />Restrições<br />Vocabulário<br />Objetos<br />Arquitetura<br />Instalação & Operação<br />Interface do usuário<br />

33.
Conceito<br />de domínio<br /> Representação<br />na análise<br /> Representação<br />no projeto<br />Livro<br />Livro<br />título<br />título<br />imprimir()<br />public class Livro<br />{<br />public void imprimir();<br />private String titulo;<br />}<br />Representação<br />no código<br />Representação de um Conceito na APOO<br />Ex.: O conceito “Livro” em um sistema de biblioteca<br />

34.
Diagramas de classes de projeto, diagramas de colaboração<br />Atribuição de responsabilidades, projeto das interações<br />Quem é responsável por o quê? Como eles interagem?<br />Uma Analogia — Organizando os Negócios de uma Empresa <br />Documentos<br />Associados<br />APOO<br />Analogia<br />Casos de uso<br />Análise de requisitos<br />Quais são os processos de negócio?<br />Modelo conceitual<br />Análise do domínio<br />Quais são os papeis dos empregados?<br />

35.
Um Exemplo — Jogo de Dados<br />Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete<br />Modelagem na APOO<br />Casos de uso<br />Descrições narrativas de processos do domínio no formato de prosa estruturada<br />Ex.: <br />Caso de uso:<br />Atores:<br />Descrição:<br />Jogar<br />Jogador<br />Este caso de uso começa quando<br />o jogador rola os dados. Se o total<br />dos dados for sete, o jogador ganha;<br />do contrário, ele perde.<br />

36.
Um Exemplo — Jogo de Dados<br />Modelagem na APOO (cont.)<br />Modelo conceitual<br />Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação<br />Ex.:<br />Um modelo conceitual descreve conceitos do mundo real, não componentes de software!<br />Jogador<br />Dado<br />2<br />1<br />Rola<br />nome<br />valor<br />2<br />1<br />Joga<br />1<br />JogoDeDados<br />1<br />Inclui<br />

37.
Um Exemplo — Jogo de Dados<br />Modelagem na APOO (cont.) <br />Diagramas de colaboração<br />Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens<br />Mostram o fluxo de mensagens entre instâncias e a invocação de métodos<br />Ex.:<br />joga()<br />1: r1 := rola()<br />:Jogador<br />d1 : Dado<br />2: r2 := rola()<br />d2 : Dado<br />

38.
Um Exemplo — Jogo de Dados<br />Modelagem na APOO (cont.) <br />Diagramas de classes de projeto<br />Como os objetos (de software) se conectam? <br />Quais são os métodos de uma classe?<br />Ex.:<br />Jogador<br />Dado<br />Rola<br />valor<br />nome<br />2<br />1<br />rola()<br />joga()<br />1<br />2<br />Joga<br />1<br />JogoDeDados<br />Inclui<br />1<br />inicializa()<br />

39.
APOO X APE<br />Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição<br />Sistema de<br />Biblioteca<br />Decomposição por objetos ou conceitos<br />Decomposição por funções ou processos<br />A&P Orientados a Objeto<br />A&P Estruturados<br />Sistema<br />Catálogo<br />Bibliotecário<br />Registra<br />Empréstimos<br />Livro<br />Adiciona<br />Recursos<br />Reporta<br />Multas<br />Biblioteca<br />

40.
A Linguagem de Modelagem Unificada — UML<br />A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto<br />A notação (a própria UML) é relativamente trivial<br />Muito mais importante: habilidade para modelar com objetos<br />Só aprender a notação UML não ajuda<br />A UML não é<br />um processo ou metodologia<br />APOO<br />regras de projeto <br />

41.
Origem e Evolução da UML<br />UML 1.1<br />Industrialização<br />(Set’97)<br />UML 1.0<br />Padronização<br />(Jan’97)<br />Parceiros<br />da UML<br />UML 0.9 & 0.91<br />Unificação II<br />(Out’96)<br />Unified Method 0.8<br />Unificação I<br />(Out’95)<br />Booch’93<br />OMT-2<br />Outros <br />métodos<br />OOSE<br />Booch’91<br />OMT-1<br />Fragmentação<br />

42.

43.
Processo de Desenvolvimento<br />Organização das atividades relacionadas à produção e manutenção de sistemas de software<br />Útil, mas um fator de segunda ordem<br />O principal: equipe qualificada<br />Boa equipe + bom processo = menor risco<br />O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria<br />

44.
Sol, Mar e UML<br />

45.
Visões da UML<br />

46.
Uma série de pesquisas (www.embeddded-forecast.com) tem mostrado que muitos projetos de software embarcados são entregues com atraso ou cancelados. <br />Em média, observou-se que mais de 50% dos projetos têm seus cronogramas atrasados em pelo menos quatro meses e cerca de 11% são cancelados.<br />

47.
O custo dos atrasos pode ser significativo. Por exemplo, no setor de aviônicos o custo dos atrasos é estimado de 50.000 a 300.000 dólares por mês.<br />Outro problema apontado é o nível de conformidade do produto final com as especificações. <br />Identificou-se que pelo menos 30% dos projetos não alcançavam 50% das especificações propostas de performance ou funcionalidade. <br />

48.
À medida que os sistemas embarcados aumentam em complexidade, esta situação tende a piorar. <br />A pesquisa mostrou também que adoção de UML (UnifiedModelingLanguage) ainda não é uma prática comum.<br />

49.
Ações (*) : unidade básica de especificação de comportamento. Ações estão contidas em atividades<br />Artefatos (*) : Pedaço físico da informação usado ou produzido durante o desenvolvimento do sistema<br />Atividades<br />Casos de Uso<br />Classes<br />Classes ativas<br />Colaboração<br />Componente<br />Estado<br />Interação<br />Interface<br />Elementos básicos do modelo UML<br />

50.
No<br />Nota<br />Pacote<br />Partes (*)<br />Portas (*)<br />Estereótipos (*)<br />Valores de etiqueta (*)<br />Restrições (*)<br />Elementos básicos do modelo UML<br />