A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

ANÁLISE OO Aspectos Avançados em Engenharia de Software Aula 2 Fernanda Campos UFJF/DCC.

Apresentações semelhantes


Apresentação em tema: "ANÁLISE OO Aspectos Avançados em Engenharia de Software Aula 2 Fernanda Campos UFJF/DCC."— Transcrição da apresentação:

1 ANÁLISE OO Aspectos Avançados em Engenharia de Software Aula 2 Fernanda Campos UFJF/DCC

2 INICIANDO A ANÁLISE Quando um software precisa ser desenvolvido? Como caracterizá-lo para a orientação a Objetos? Quais os objetos relevantes? Como eles se relacionam? Como os objetos se comportam no contexto do software? Como especificar ou modelar o problema para desenvolver um projeto efetivo?

3 ANÁLISE OO A análise OO busca responder a essas questões, sendo ela a primeira atividade do processo de desenvolvimento.

4 PRINCÍPIOS DO MODELO DE ANÁLISE Modelar o domínio da aplicação Descrever os módulos de funções Representar o modelo de comportamento Particionar os modelos para expor melhor os detalhes Modelos iniciais representam a essência do problema, enquanto os modelos posteriores fornecem detalhes de implementação.

5 OBJETIVO DA ANÁLISE OO O objetivo da AOO é definir todas as classes (relacionamentos e comportamento) que são relevantes para a solução do problema a ser resolvido.

6 TAREFAS DA OOA 1. Requisitos básicos do usuário devem ser comunicados entre usuário e engenheiro de software. 2. Classes devem ser identificadas (atributos e métodos devem ser definidos) 3. Uma hierarquia de classes deve ser especificada 4. Relacionamentos objetos para objetos (conexões) devem ser representados 5. O comportamento de cada objeto deve ser modelado Tarefas de 1 a 5 devem ser interativamente repetidas até que o modelo se complete.

7 ANÁLISE OO Em vez de examinar o problema numa abordagem entrada-processamento- saída a OO introduz uma concepção mais natural. Parte da observação do comportamento dos objetos.

8 ANÁLISE OO O objetivo da AOO é desenvolver uma série de modelos que descrevam como o software funciona para atender aos requisitos do usuário. Constrói um modelo de análise em múltiplas partes para satisfazer os objetivos. O modelo de análise depende de informações, funções e comportamentos no contexto dos requisitos do software.

9 MODELOS DE OOA Método de Booch Modelo de Coad e Yordon Método de Jacobson Modelo de Rambaugh Modelo de Wirts-Brock

10 UML - Unified Modeling Language UML Booch Rumbaugh Jacobson Meyer Harel Wirfs-Brock Fusion Gamma et al. Shlaer-Mellor Odell

11 Representação de um sistema em UML Cinco visões cada uma definida por um conjunto de diagramas: Visão do modelo do usuário representa o sistema a partir da perspectiva do usuário, atores em UML. Casos de uso Visão do modelo estrutural Dados e funcionalidades são vistos de dentro do sistema, a estrutura estática é modelada (classes, objetos e relacionamentos). Diagrama de classes

12 Representação de um sistema em UML Visão do modelo comportamental Representa os modelos dinâmicos ou comportamentais do sistema e mostra também as interações ou colaborações entre os vários elementos estruturais descritos nas outras visões. Diagramas de seqüências, atividades, estado, cooperação. Visão do modelo de implementação Os aspectos estruturais e comportamentais são representados da forma como devem ser construídos. Diagrama componentes e implantação Visão do modelo do ambiente Os aspectos estruturais e comportamentais do ambiente, no qual o sistema deve ser implementado devem ser representados. Diagrama de implantação.

13 Análise de Domínio

14 ANÁLISE DE DOMÍNIO A análise de domínio é a identificação, análise e especificação de requisitos comuns de um domínio específico de aplicação, tipicamente para reutilização em múltiplos projetos dentro da aplicação do domínio (Firesmith, 1993).

15 ANÁLISE DE DOMÍNIO A Análise de Domínio para sistemas OO pode ocorrer em diferentes níveis de abstração. No nível de empresas e negócios as técnicas associadas com a Análise OO podem ser acopladas a diversas abordagens de Engenharia de Software no esforço de definir classes, objetos, relacionamentos e comportamentos que modelam todo o negócio. A nível de área de negócio um modelo e objetos que descrevem o trabalho de uma área especial do negócio podem ser definidos. No nível da aplicação o modelo de objeto foca nos requisitos de um usuário ou cliente na medida em que esses requisitos afetam a aplicação a ser construída.

16 ANÁLISE DE DOMÍNIO É comum a proposta de se trabalhar num nível médio de abstração da análise de domínio, que se caracteriza pelo desejo da empresa em criar uma biblioteca de classes reutilizáveis (componentes) que será largamente utilizada numa categoria inteira de aplicações.

17 ANÁLISE DE DOMÍNIO Um domínio específico de aplicação pode variar muito (aplicações bancárias, multimídia, etc) mas o objetivo da análise de domínio é identificar e criar classes que serão largamente aplicáveis, de forma que sejam reutilizadas.

18 ANÁLISE DE DOMÍNIO A analise de domínio pode ser vista como uma atividade guarda chuva para o processo de desenvolvimento de software. Não está diretamente relacionada a um projeto de software específico, já que seu objetivo e desenvolver componentes reutilizáveis.

19 ANÁLISE DE DOMÍNIO Entradas e saídas chaves para o processo de análise de domínio. Figura 8.2 página 147 – Pressman 6ª Edição

20 PROCESSO DE ANÁLISE DE DOMÍNIO A análise de domínio pode ser caracterizada por uma série de atividades que se iniciam com a identificação do domínio a ser investigado e termina pela especificação das classes e objetos que caracterizam o domínio.

21 ATIVIDADES ( Berard, 1993) 1. Definir o domínio a ser investigado. identificar áreas de negócios, tipo de sistema, interesse do produto, aplicações OO e não OO já definidas, casos de testes, planos, padrões, métricas, etc. 2. Categorizar os itens extraídos do domínio de forma a estabelecer uma hierarquia de classificação. Elaborar uma taxionomia. 3 Coletar uma amostra representativa das aplicações do domínio garantindo que durante a análise os itens da aplicação se enquadrem nas categorias definidas.

22 ATIVIDADES ( Berard, 1993) Analisar cada aplicação na amostra, segundo os passos da analise de domínio identificar objetos reutilizáveis candidatos indicar as razões pelas quais o objeto foi identificado para reuso. definir adaptações no objeto que também podem ser reutilizadas estimar a porcentagem de aplicações no domínio que podem fazer reuso do objeto identificar os objetos pelo nome e usar técnicas de configuração e gerenciamento para controlá-los. Desenvolver um modelo de análise para os objetos. O modelo de análise servirá de base para o projeto e construção dos objetos de domínio

23 PROCESSO DE ANÁLISE DE DOMÍNIO Além desses passos a análise de domínio deve criar um conjunto de diretrizes e desenvolver exemplos que ilustrem como os objetos do domínio podem ser usados para criar novas aplicações. O objetivo é desenvolver software no domínio com alto percentual de reutilização, baixo custo, alta qualidade e curto prazo de comercialização.

24 PROCESSO DE ANÁLISE OO O processo da Análise OO não se inicia com os objetos, mas pelo entendimento da maneira como o software será usado pelas pessoas - se é um sistema interativo pelas máquinas - se é um sistema de controle de processo por outros programas - se o sistema controla outras aplicações. Tão logo este cenário de uso é identificado a modelagem do sistema se inicia.

25 PROCESSO DE ANÁLISE OO Alguns modelos podem auxiliar o levantamento de requisitos do usuários como o casos de uso.

26 Casos de uso Requisitos de software são sempre a primeira atividade da análise. Baseado nestes requisitos o engenheiro de software pode criar cenários para identificar os usos do software a ser construído Os cenários, chamados casos de uso, descrevem como o software será usado.

27 Casos de uso Para criar um caso de uso primeiro identifica-se os tipos de pessoas (ou equipamentos) que usarão o sistema ou produto. Em geral esses atores representam papéis na operação do sistema. O ator se comunica com o sistema ou produto, mas, é externo a ele.

28 Casos de usos Atores e usuários são diferentes Um usuário pode ter vários papéis quando usando o sistema Um ator representa um classe de entidades externas

29 Casos de usos Começa-se por fazer a pergunta: O que é que os usuários do sistema podem fazer e como é que o sistema responde? É necessário determinar quem são os usuários e demais intervenientes que interagem com o sistema. A esses intervenientes dá-se o nome de atores. Nos diagramas de casos de uso os atores são representados por: NOME

30 Casos de usos Um ator é sempre um elemento externo ao sistema. Para descobrir atores podemos fazer as seguintes perguntas: Quem usa o sistema? Quem instala o sistema? Quem inicia o sistema? Quem faz a manutenção do sistema? Quem desliga o sistema? Que outros sistemas usam este sistema? Quem recebe informação sobre este sistema? Quem fornece informação ao sistema? O que acontece automaticamente no sistema?

31 Casos de usos Depois de identificarmos os atores, é necessário identificar casos de uso para cada um Um caso de uso é um modo de os atores usarem o sistema. É uma ação que um ator pode realizar no sistema.

32 Casos de usos Para identificar casos de uso podemos fazer as seguintes perguntas: Que funções pretende o ator do sistema? Que informação armazena o sistema? Quais atores vão utilizar essa informação? O sistema precisa de avisar os atores sobre as mudanças do seu estado interno? Há acontecimentos externos ao sistema que este necessite saber? Se, sim quem fornece tal informação?

33 Casos de usos Em geral um caso de uso se resume na descrição do papel do ator ao interagir com o sistema. Deve fornecer um cenário não ambíguo da interação entre atores e software.

34 Casos de usos O processo de identificação dos casos de uso é interativo. Não é necessário identificar de imediato todos os atores. Depois de identificados os atores e respectivos casos de uso elabora-se um diagrama de casos de uso.

35 Casos de uso - representações Nome do caso de uso Sistema

36 Casos de uso - representações ator 1 ator 2 ator 3 casos de uso 1 casos de uso 2 casos de uso 3 casos de uso 4

37 Identificação das classes Após o desenvolvimento de cenários para o sistema é hora de identificar classes candidatas.

38 Definição de Estruturas e Hierarquias Uma vez classes e objetos sejam identificados, o analista inicia o modelo de estrutura das classes e das hierarquias. É o momento da elaboração de diagramas de classes com generalização- especialização e/ou todo-parte.

39

40 Definição do Modelo de Relacionamento O primeiro passo para entender o relacionamento entre classes é identificar as responsabilidades de cada classe. O segundo passo é identificar os colaboradores das classes que as ajudam a alcançar cada responsabilidade. Aí é estabelecida a conexão entre classes.

41 Definição do Modelo de Relacionamento O relacionamento existe entre duas classes conectadas. Colaboradores estão sempre conectados de alguma forma. O tipo mais comum de relacionamento é o binário – uma conexão entre duas classes (cliente-servidor).

42 Diagrama de Colaboração Computador ServidorPrinter FilaPrinter 1:Print(File) [Printer ocupada] 1:2:Store(File) [Printer livre]1:1:Print(File)

43 Definição do Modelo de Comportamento O modelo de classes e objetos representam elementos estáticos do modelo de análise OO. Para projetar a transição para o comportamento dinâmico do sistema é necessário representar o comportamento do sistema em função dos eventos e do tempo. Os diagramas de estado e seqüência indicam como o sistema irá responder aos eventos externos e aos estímulos.

44 Diagrama de Estado Registrando o pedido Alterando o pedido Cancelando o pedido Analisando o pedido Atendendo o pedido Aprovando o pedido Colocando o pedido em pendência Pedido enviado Alteração de Pedido solicitada Cancelamento de pedido solicitado Pedido cancelado Pedido será cancelado Pedido para análise requisitado Pedido para aprovação Pedido já pode ser atendido Pedido não pode ser atendido no momento Pedido será atendido Pedido atendido

45 Diagrama de Seqüência : Bibliotecário : Título : Leitor : Janela Empréstimo : Empréstimo : Item 1: ache título ( ) 2: $ache (String) 3: ache Item ( ) 5: identifica leitor ( ) 6: $ache (String) 7: criar (leitor, Item) 4: $ache título (Titulo) Emprestando sem reserva

46 UML - Unified Modeling Language DIAGRAMAS Diagrama de Casos de Uso Diagrama de Classes Diagrama de Objetos Diagrama de Estado Diagrama de Seqüência Diagrama de Colaboração Diagrama de Atividades Diagrama de Componentes Diagrama de Desenvolvimento

47 UML - Unified Modeling Language DIAGRAMAS Diagrama de Casos de Uso: Atores e suas conexões com Casos de Uso Diagrama de Classes: Estrutura estática das classes do sistema Diagrama de Objetos: Exemplifica Diagrama de Classes Complexo Diagrama de Estado: Estados possíveis que objetos de uma classe pode ter e que eventos causam a mudança de estado

48 UML - Unified Modeling Language DIAGRAMAS Diagrama de Seqüência: Colaboração Dinâmica através troca de mensagens entre objetos a partir de uma função ou seqüência de tempo Diagrama de Colaboração: Colaboração Dinâmica através da interação entre objetos (ênfase no contexto) Diagrama de Atividades: Fluxo seqüencial das atividades Diagrama de Componentes: Estrutura Física de código em termos de componentes de código Diagrama de Desenvolvimento: Arquitetura Física do Hardware e Software


Carregar ppt "ANÁLISE OO Aspectos Avançados em Engenharia de Software Aula 2 Fernanda Campos UFJF/DCC."

Apresentações semelhantes


Anúncios Google