Pontifícia Universidade Católica de São Paulo Departamento de Ciência da Computação

Transcrição

1 Pontifícia Universidade Católica de São Paulo Departamento de Ciência da Computação Dr. Ítalo S. Vega ES-II/III: Engenharia de Software: Processos Projeto 1 c 2004, ISVega Ferramenta CASE: LiMAOO-PUC CONTEÚDO 1.1 Descrição Geral Introdução Configuração do Sistema Interação do Sistema Edição de Classes Exemplo Sobre a Avaliação Descrição Geral Introdução Normalmente, a fabricação de um sistema de software faz uso de ferramentas denominadas CASE (Computer Aided Software Engineering). Tais ferramentas podem ser altamente sofisticadas e caras, mas também podem ter objetivos mais modestos. O projeto a ser desenvolvido em ESII/III no ano de 2004 envolve a construção de uma ferramenta CASE deste último tipo. O sistema deverá ter a capacidade de apresentar modelos de objetos em modo gráfico e em modo texto, com suporte para a elaboração de cenários escritos em LiMAOO-PUC (Linguagem para Modelos de Análise Orientados a Objetos), e com geração de modelos de implementação em Java. O ciclo de programação convencional pode ser caracterizado pela realização das atividades edita-compila-executa. Uma vez concluída, a ferramenta CASE deverá per- 1

2 ES-II/III: Projeto 1 - c 2004, ISVega Ferramenta CASE: LiMAOO-PUC 2 mitir a substituição deste ciclo convencional por outro ciclo de modelagem da forma analisa/projeta-compila-executa. A fase de edição do programa-fonte é substituída por uma fase de análise/projeto orientados a objetos. Não há a necessidade do usuário interagir diretamente com os fontes em Java. Caso ocorra um erro de execução, ele deve ser reportado para o modelador e o ciclo de modelagem reiniciado. A ferramenta irá recriar o modelo executável a partir do modelo revisado Configuração do Sistema O sistema CASE deverá ter as seguintes opções de configuração: diretório de trabalho; editor do texto da especificação (notepad.exe, por exemplo); módulo de geração do programa-fonte (em Java, em C++, em Delphi,...); coleções-padrão para associações com multiplicidade n Interação do Sistema Após a carga inicial da ferramenta, o modelador deverá indicar se deseja criar um novo projeto ou continuar um projeto anterior. Em ambos os casos, o sistema deverá aceitar comandos para processamento do modelo sendo desenvolvido. Tais comandos envolvem, entre outros: criar um modelo de classes; criar um modelo de instâncias; criar um modelo de seqüências de mensagens; ver o texto em LiMAOO-PUC; gerar códigos-fonte. Na parte inferior desta tela principal, deverá existir um campo para mensagens sobre o andamento da modelagem Edição de Classes Para inserir uma nova classe no modelo, a ferramenta deverá apresentar uma janela de diálogo solicitando suas principais informações: nome da classe, uma indicação se ela é abstrata ou persistente, eventuais invariantes, etc. (É importante que exista a possibilidade de se documentar a classe com comentários.)

3 ES-II/III: Projeto 1 - c 2004, ISVega Ferramenta CASE: LiMAOO-PUC 3 Além disso, o editor de classes deverá suportar a edição dos atributos e operações da classe. Para cada atributo, devem ser fornecidos o seu nome e o seu tipo. No caso das operações da classe, o modelador deverá ser capaz de informar: o nome da operação (com eventuais argumentos), o grau de acesso da operação (público, protegido ou privado), uma combinação de qualificadores (estática, substituição, deferida ou polimórfica) e a respectiva lógica do seu método. O método, por sua vez, será modelado em três partes: o que ele exige (pré-condição), o seu algoritmo e o que ele garante ao término da sua execução (pós-condição). O algoritmo de um método poderá incluir os seguintes comandos da LiMAOO-PUC: se... então... instancie... para... em... fazer... envie... para... enquanto... fazer... retorne Exemplo Seja o caso de uma fábrica composta por diversos departamentos onde vários empregados realizam os seus turnos. Um possível modelo para esta situação é apresentado no diagrama de classes UML da Figura 1.1. Departamento - nome : Texto * Fábrica Empregado + Departamento(umNome : Texto) : Departamento + nome?() : Texto * Figura 1.1: Fábricas, departamentos e empregados. Parte do modelo dinâmico referente aos objetos da classe Departamento é mostrado no diagrama de seqüências de mensagens UML apresentado na Figura 1.2.

4 ES-II/III: Projeto 1 - c 2004, ISVega Ferramenta CASE: LiMAOO-PUC 4 1: <<create>> Departamento() 1.1: mudar(novo) 2: nome?() nome Figura 1.2: Modelo dinâmico parcial de um departamento. A ferramenta deverá ser capaz de mostrar, graficamente, este diagrama de classes. Caso o gerador LiMAOO-PUC fosse acionado sobre a classedepartamento, o seguinte texto seria obtido: classe Departamento especificação: interface pública Departamento( umnome : Texto ) nome? -> Texto interface protegida estrutura privada atributos nome : Texto associações agregações comportamento privado método Departamento( novo : Texto ) lógica envie mudar( novo ) para nome fim método Departamento método nome? -> Texto lógica retorne nome fim método nome? fim classe Departamento

5 ES-II/III: Projeto 1 - c 2004, ISVega Ferramenta CASE: LiMAOO-PUC Sobre a Avaliação Datas Importantes Atividade A1 Data Divulgação das Tarefas 02/04/2004 Entrega dos Resultados 24/04/2002 Os seguintes artefatos de requisitos deverão ser entre- Artefatos de Requisitos gues: (50 pontos) modelo de casos de uso contemplando, no mínimo, cinco casos de negócio (a clareza de intenções dos casos de uso elaborados será crítico nesta avaliação); (20 pontos) glossário de termos de negócio e outros, necessários para a compreensão dos casos de uso; (10 pontos) cronograma inicial de trabalho do time, organizado por semanas, com indicação dos artefatos primários a serem produzidos; (sugestão: considerar a extensão do cronograma de abril a novembro - inclusive - em função de dois ciclos de desenvolvimento.)