UML - Processos e Ferramentas CASE · que é o UML (Unified Modeling Language), como aplicar o UML...

Centro Atlântico

UML, Processos eFerramentas CASE

Alberto SilvaCarlos Videira

UML, Processos eFerramentas CASEBeta-Book em 05 de Dezembro de 2000(versão definitiva em Fevereiro de 2001)

Edições Centro AtlânticoPortugal/2001

beta-book em www.centroatlantico.pt/titulos/tecnologias/uml.html

Reservados todos os direitos por Centro Atlântico, Lda.Qualquer reprodução, incluindo fotocópia, só pode ser feitacom autorização expressa dos editores da obra.

UML - Processos e Ferramentas CASEColecção: TecnologiasAutor: Alberto Silva e Carlos VideiraDirecção gráfica: Centro AtlânticoRevisão: Centro AtlânticoCapa: Paulo Buchinho

© Centro Atlântico, Lda., 2001Av. D. Afonso Henriques, 1462 - 4450 MatosinhosTel. 22 - 938 56 28/9 Fax. 22 - 938 56 30Rua da Misericórdia, 76 - 1200 LisboaTel. 21 - 321 01 95 Fax 21 - 321 01 [email protected]

Fotolitos: Centro AtlânticoImpressão e acabamento: Inova1ª edição: Fevereiro de 2001

ISBN: 972-8426-Depósito legal: ../01

Marcas registadas: todos os termos mencionados neste livro conhecidos como sendo marcas registadasde produtos e serviços, foram apropriadamente capitalizados. A utilização de um termo neste livronão deve ser encarada como afectando a validade de alguma marca registada de produto ou serviço.O Editor e os Autores não se responsabilizam por possíveis danos morais ou físicos causados pelasinstruções contidas no livro nem por endereços Internet que não correspondam às Home-Pagespretendidas.

Prefácio

Objectivos, Contexto e Motivação

O livro “UML, Processos e Ferramentas CASE” aborda tópicos importantes paraa generalidade dos estudantes e das empresas de engenharia e consultoria desoftware, designadamente as problemáticas (1) da linguagem de modelação desoftware; (2) do processo de desenvolvimento de software; e (3) das ferramentasCASE de suporte à modelação e ao próprio desenvolvimento. Pretende dar umapanorâmica abrangente sobre estes três aspectos de forma integrada e coerente.O livro explica a necessidade da modelação no desenvolvimento de software, oque é o UML (Unified Modeling Language), como aplicar o UML no contexto maisabrangente do processo, e como usar ferramentas CASE de forma a maximizare automatizar algumas das tarefas correlacionadas com a modelação: produçãoe gestão de documentação, geração de código, geração de esquemas de dados;reverse engineering, etc.

A aprendizagem e adopção dos tópicos tratados constituem uma decisivavantagem para as empresas que os adoptarem consistentemente. Entre outros,salientamos os seguintes benefícios. (1) melhor documentação dos sistemas erespectivos artefactos; (2) modelação baseada em objectos, mais fácil deentender; (3) reutilização desde as fases preliminares da concepção até àimplementação; (4) rastreabilidade, (5) facilidade de comunicação entre todosos intervenientes envolvidos; (6) flexibilidade e produtividade; (7) melhor gestãode requisitos, avaliação e manutenção de sistemas. Estas características sãonaturalmente interdependentes entre si. Por exemplo, o melhor nível dedocumentação produzida implica uma melhor comunicação entre osintervenientes de um projecto ou uma melhor manutenção.

Todavia, o assunto tratado é difícil de adoptar nas empresas de engenharia desoftware por inúmeras razões. Antes de mais porque as vagas tecnológicasnesta área da engenharia têm surgido, como se sabe, a ritmos muito elevados.

A segunda razão deve-se ao facto dos tópicos abordados neste livro exigiremuma formação significativa e principalmente uma adequada e correspondenteformação-acção. Não basta dominar um conjunto alargado de conceitos enotações para especificar software, mas (1) é imperioso aprender a aplicá-losde forma consistente, repetida e sistemática; (2) adaptá-los às condicionantes erealidades de cada empresa, ou de cada projecto em particular; e ainda (3)

6 CENTRO ATLÂNTICO - COLECÇÃO TECNOLOGIAS

partilhar técnicas e métodos entre todos os indivíduos da empresa ou de cadaprojecto para que a comunicação entre todos os intervenientes seja maximizadae eficiente.

A terceira razão, consequência das razões anteriormente referidas, é o facto deser oneroso a adopção efectiva e produtiva (dos tópicos abordados neste livro)no seio deste tipo de empresas. Oneroso em termos do tempo inicial que énecessário despender em formação, em termos da “resistência à mudança”,assim como o investimento necessário na selecção e aquisição de ferramentasCASE que potenciem significativamente as suas vantagens.

Este livro surge na sequência da nossa experiência e actividade de investigaçãomas principalmente de consultoria e de docência nas áreas de engenharia desoftware e de sistemas de informação.

É um livro que condensa e integra informação dispersa por alguns livros daárea, em particular os seguintes títulos: OMG Unified Modeling Language Speci-fication, The Unified Modeling Language User Guide, The Unified Software De-velopment Process, Use Case Driven Object Modeling with UML e Visual Mod-eling with Rational Rose 2000 and UML.

Os temas abordados neste livro são na sua maioria “contributos inovadores”dos “três amigos” G. Booch, I. Jacobson e J. Rumbaugh. Todavia, é da nossaexclusiva responsabilidade o estilo do livro, assim como a sua estrutura, conteúdo,exemplos, e exercícios propostos (tal como as correspondentes gralhas eomissões decorrentes!).

Embora exista um número relevante de títulos nesta área em termos mundiais,há em língua Portuguesa um défice muito significativo. Por outro lado, comoconsequência da nossa experiência e responsabilidade de docência, supervisãoe coordenação de trabalhos finais de curso e de investigação identificámos anecessidade e oportunidade de produzirmos este livro com vista a apoiar aaprendizagem da engenharia de software nos tópicos referidos.

Audiência do Livro

O livro pretende servir como referência de suporte à realização de diferentesdisciplinas de nível de ensino superior na área de sistemas de informação.

7UML, PROCESSOS E FERRAMENTAS CASE - BETA-BOOK

Consequentemente, o livro adopta um estilo tendencialmente pedagógico, porexemplo, através da apresentação e discussão de exemplos, da narrativa dehistórias e factos reais (e.g., situações típicas de erros a evitar), ou pela propostade exercícios académicos.

O primeiro perfil de leitura deste livro vai directamente para os alunos delicenciaturas e cursos de pós-graduação em engenharia informática ou eminformática de gestão. Estes leitores já sabem “implementar” aplicaçõesinformáticas, mas vão aprender a reflectir sobre o processo de desenvolvimentode software e aprender técnicas e práticas consistentes e sistemáticas para orealizar.

Adicionalmente, este livro é relevante para um número mais alargado de leitores,em particular para gestores informáticos, responsáveis pelo processo dedesenvolvimento de software, analistas-programadores, e outros que necessitemde especificar de forma mais ou menos detalhada sistemas de software.

O livro pressupõe um conjunto de pré-requisitos que o leitor deverá possuir parao poder usufruir devidamente. Nomeadamente, um conhecimento razoável sobreas bases da informática e dos sistemas de computadores, tais como noçõesessenciais de programação, de bases de dados e de sistemas operativos.

Organização do Livro

O livro encontra-se organizado em 4 partes, 15 capítulos e 2 apêndices conformese resume de seguida.

A Parte 1 (INTRODUÇÃO E VISÃO GERAL) apresenta os conceitos gerais, visão históricae enquadramento da realização deste livro. Inclui os capítulos 1, 2 e 3.

A Parte 2 (LINGUAGEM DE MODELAÇÃO UML) apresenta a linguagem de modelaçãoUML numa perspectiva didáctica, abrangente e independente do domínio deaplicação ou do processo de desenvolvimento. Inclui os capítulos 4 a 9.

A Parte 3 (PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE) apresenta a problemáticageral dos processos de desenvolvimento de software, com exemplos concretosem dois processos actuais, o RUP e o Iconix. Inclui os capítulos 10 a 12.

A Parte 4 (FERRAMENTAS CASE) apresenta a problemática das ferramentas CASE


descrevendo o seu significado, evolução histórica e discutindo mecanismos decaracterização e avaliação. São avaliadas duas ferramentas CASE, o Rose daRational e o System Architect da Popkin. Inclui os capítulos 13 a 15.

No Apêndice A (“Guia de Recursos Electrónicos”) apresentam-se de modoclassificado e comentado um conjunto significativo de recursos electrónicossobre o tema abordado neste livro.

No Apêndice B (“Glossário, Siglas e Abreviaturas”) apresentam-se três tabelascom informação de, respectivamente: o glossário, as siglas, e as abreviaturasadoptadas ao longo de todo o livro.

Em “Referências” listam-se, por ordem alfabética todas as referênciasbibliográficas utilizadas ao longo do livro.

Notação Adoptada

Ao longo do livro são adoptadas genericamente as seguintes regras de notaçãotextual:• Nomes e expressões em inglês são escritas em itálico. As excepções são

expressões vulgarmente adoptadas para o Português (e.g., software, bit),expressões intensamente usadas ao longo do texto (e.g., Internet, Web,applet), ou nomes de produtos de origem anglo-saxónica (e.g., MS-Word,Rational Rose).

• Frases e expressões que se pretendam destacar são escritas com ênfase(i.e., negrito).

• Exemplos de código, pseudo código, nomes de classes, ou endereços elec-trónicos são apresentados numa fonte de tamanho fixo (i.e., Courier).

Relativamente à representação de diagramas será utilizada, sempre que foradequado, e por razões óbvias, a linguagem UML.

Lisboa, Novembro de 2000

Alberto Manuel Rodrigues da SilvaCarlos Alberto Escaleira Videira


Índice

PREFÁCIO

ÍNDICE

LISTA DE FIGURAS E TABELAS

LISTA DE EXEMPLOS

PARTE 1 – INTRODUÇÃO E VISÃO GERAL

CAPÍTULO 1 - INTRODUÇÃO1.1 O Impacto das Tecnologias de Informação1.2 Produto e Processo1.3 Objectivos a atingir com o desenvolvimento de software1.4 Problemas com o Software1.5 Classificações do Software

CAPÍTULO 2 - O PROCESSO DE DESENVOLVIMENTO DESOFTWARE

2.1 A Importância da Abstracção e da Modelização2.2 Princípios da Modelação2.3 Onde Começa o Processo de Desenvolvimento de Software2.4 Planeamento Estratégico de Sistemas de Informação2.5 Engenharia de Software2.6 Sistemas de Informação

2.6.1 Arquitectura de Sistemas de Informação2.7 Problemas no Desenvolvimento de Software2.8 Ciclos de Vida de Desenvolvimento de Sistemas de Informação

CAPÍTULO 3 - EVOLUÇÃO HISTÓRICA DOS MÉTODOS DE DESEN-VOLVIMENTO DE SOFTWARE

3.1 Conceitos básicos3.2 Apresentação de Diferentes Classificações3.3 SEI - CMM3.4 O Desenvolvimento AD-HOC


3.5 Métodos de A&D Estruturados3.5.1 Motivações3.5.2 Conceitos básicos3.5.3 Notações mais Utilizadas3.5.4 Metodologias e Respectivo Enfoque3.5.5 SSADM

3.6 Métodos de A&D Baseados em Objectos3.6.1 Motivações3.6.2 Conceitos Básicos3.6.3 Notações mais Utilizadas3.6.4 Metodologias e Respectivo Enfoque3.6.5 RUP

3.7 Comparação entre Métodos Estruturados e O-O3.7.1 Gestão de Requisitos e Facilidade de Manutenção3.7.2 Representação da Realidade3.7.3 Outros Aspectos

3.8 O Futuro dos Métodos de Desenvolvimento

PARTE 2 – LINGUAGEM DE MODELAÇÃO UML

CAPÍTULO 4 - UML – VISÃO GERAL4.1 Introdução4.2 Visão Histórica4.3 Tipos de Elementos Básicos4.4 Tipos de Relações4.5 Tipos de Diagramas

4.5.1 Diagramas de Casos de Utilização4.5.2 Diagramas da Estrutura Estática4.5.3 Diagramas da Dinâmica ou do Comportamento4.5.4 Diagramas de Implementação

4.6 Mecanismos Comuns4.6.1 Notas (Anotações)4.6.2 Mecanismos de Extensibilidade

4.7 Organização dos Artefactos - Pacotes4.7.1 Representação Gráfica4.7.2 Relações entre Pacotes4.7.3 Tipos de Pacotes4.7.4 Modelação de Grupos de Elementos

CAPÍTULO 5 - UML – MODELAÇÃO DE REQUISITOS5.1 Introdução5.2 Casos de Utilização

5.2.1 Casos de utilização e Cenários


5.2.2 Relações entre Casos de utilização5.3 Diagramas de Casos de Utilização

5.3.1 Actores5.3.2 Casos de Utilização Abstractos

5.4 Exemplo – A Máquina de Bebidas5.5 Exercícios

CAPÍTULO 6 - UML – MODELAÇÃO DA ESTRUTURA6.1 Introdução6.2 Classes6.3 Relações

6.3.1 Relação de Dependência6.3.2 Relação de Generalização6.3.3 Relação de Associação

6.4 Interfaces6.5 Instâncias e Objectos6.6 Diagramas de Objectos6.7 Exemplos e Avisos6.8 Exercícios

CAPÍTULO 7 - UML – MODELAÇÃO DO COMPORTAMENTO7.1 Introdução7.2 Interacções

7.2.1 Objectos e Ligações7.2.2 Mensagens e Estímulos7.2.3 Representação de Mensagens7.2.4 Tipos de Mensagens

7.3 Diagramas de Interacção7.3.1 Diagrama de Sequências7.3.2 Diagrama de Colaboração7.3.3 Equivalência Semântica7.3.4 Diagramas de Interação e de Casos de Utilização

7.4 Diagramas de Estado7.4.1 Estados7.4.2 Transições7.4.3 Eventos7.4.4 Acções e Actividades7.4.5 Sub-Estados

7.5 Diagramas de Actividade7.5.1 Decisões7.5.2 Caminhos Concorrentes7.5.3 Pistas (Swimlanes)7.5.4 Actividades e Objectos7.5.5 Envio e Recepção de Sinais7.5.6 Utilizações Típicas

7.6 Exercícios


CAPÍTULO 8 - UML – MODELAÇÃO DA ARQUITECTURA8.1 Introdução8.2 Componentes e Nós

8.2.1 Componentes8.2.2 Nós8.2.3 Relações entre Nós e Componentes

8.3 Diagramas de Componentes8.4 Diagramas de Instalação8.5 Exercícios

CAPÍTULO 9 - UML – ASPECTOS AVANÇADOS9.1 Introdução9.2 A Arquitectura do UML

9.2.1 A Estrutura do UML a Quatro Camadas9.3 Mecanismos de Extensão9.4 Perfis UML

9.4.1 Perfil para Processos de Desenvolvimento de Software9.4.2 Perfil para Modelação de Negócios9.4.3 Perfil para Modelação de Aplicações Web

9.5 XMI – XML Metadata Interchange

PARTE 3 – PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

CAPÍTULO 10 - PROCESSOS DE DESENVOLVIMENTO DESOFTWARE

10.1 Introdução e visão histórica10.2 Processos Tradicionais10.3 Processos Baseados em Objectos

CAPÍTULO 11 - PROCESSO RUP11.1 Introdução e Visão Histórica11.2 Visão Geral11.3 RUP e UML11.4 Características mais relevantes11.5 Fases do Processo RUP


CAPÍTULO 12 - PROCESSO ICONIX12.1 Introdução e Visão Histórica12.2 Visão Geral12.3 Iconix e UML12.4 Características mais relevantes12.5 Fases do Processo Iconix

PARTE 4 – FERRAMENTAS CASE

CAPÍTULO 13 - FERRAMENTAS CASE13.1 O que Significa CASE13.2 Evolução Histórica13.3 Áreas de Intervenção das Ferramentas CASE13.4 Classificações das Ferramentas CASE13.5 Avaliação das Ferramentas CASE

13.5.1 Mercado Actual13.5.2 Critérios de Avaliação13.5.3 Resultados da Avaliação

13.6 O Futuro das Ferramentas CASE13.7 Caso de Estudo para Avaliação

CAPÍTULO 14 - RATIONAL ROSE14.1 Porquê Avaliar o Rational Rose14.2 Principais Características da Ferramenta14.3 Resolução do Caso de Estudo

CAPÍTULO 15 - SYSTEM ARCHITECT15.1 Porquê Avaliar o System Architect15.2 Principais Características da Ferramenta15.3 Resolução do Caso de Estudo


Lista de Figuras e TabelasTabela 1.1 - Ondas de Inovação de Primozic

Tabela 1.2 - Estatisticas diversas obtidas ao longo do tempo sobre os projectos de

desenvolvimento de software

Tabela 1.3 - Exemplos de sistemas segundo a classificação de Anthony.

Figura 2.1: Custo relativo de correcção de erros ao longo do ciclo de vida de um projecto.

Figura 2.2: Exemplo de um ciclo de vida de um projecto de software.

Figura 2.3: Actividades realizadas na fase de concepção.

Figura 3.1: Relações entre os conceitos de UoD, EMR, modelos e esquemas.

Figura 3.3: Visão histórica dos métodos de desenvolvimento de software.

Figura 3.4: Desenvolvimento estruturado vs. desenvolvimento baseado em objectos.

Figura 3.5: A solução do problema do ano 2000 segundo a abordagem OO.

Figura 3.6: Distribuição de uma aplicação.

Figura 3.7: Especialização de contas bancárias na abordagem OO.

Figura 4.1: Visão histórica do UML.

Figura 4.2: Resumo dos elementos de estrutura.

Figura 4.3: Resumo dos elementos de comportamento, agrupamento e anotação.

Figura 4.4: Resumo dos tipos de relações standard.

Figura 4.5: Exemplo de um diagrama de casos de utilização.

Figura 4.6: Exemplo de um diagrama de classes.

Figura 4.7: Exemplo de um diagrama de actividades.

Figura 4.8: Exemplo de um diagrama de instalação.

Figura 4.9: Exemplo de notas.

Figura 4.10: Exemplo de estereótipos.

Figura 4.11: Exemplo de marcas com valor.

Figura 4.12: Exemplos de utilização de restrições.

Figura 4.13: Exemplos de pacotes.

Figura 4.14: Relações de importação/exportação entre pacotes.

Figura 4.15: Relações de generalização entre pacotes.

Figura 5.1: Representação gráfica de casos de utilização.

Figura 5.2: Relação de generalização entre casos de utilização.

Figura 5.3: Relação de inclusão entre casos de utilização.

Figura 5.4: Relação de extensão entre casos de utilização.

Figura 5.5: Diagrama de casos de utilização.

Figura 5.6: Relação de hierarquia entre actores.

Figura 5.7: Diagrama de casos de utilização da “Máquina de Bebidas” – preliminar.

Figura 5.8: Diagrama de casos de utilização da “Máquina de Bebidas” – com inclusão.

Figura 5.9: Diagrama de casos de utilização da “Máquina de Bebidas” – com extensão.

Figura 6.1: Representação de uma classe em UML.

Figura 6.2: Apresentação dos atributos e operações de uma classe.


Figura 6.3: Usando estereótipos para organizar a lista de operações de uma classe.

Figura 6.4: Dependência entre classes.

Figura 6.5: Relação de generalização entre classes.

Figura 6.6: Relação de associação entre classes.

Figura 6.7: Adornos comuns usados em relações de associação.

Figura 6.8: Navegação numa relação de associação.

Figura 6.9: Agregação simples numa relação de associação.

Figura 6.10: Agregação composta numa relação de associação.

Figura 6.11: Associação com qualificador.

Figura 6.12: Associação reflexiva.

Figura 6.13: Classe-associação.

Figura 6.14: Associação ternária e uma classe-associação.

Figura 6.15: Noção de interface.

Figura 6.16: Várias representações para a interface Enumeration.

Figura 6.17: Utilização de interfaces em diagramas de classe.

Figura 6.18: Utilização de interfaces em diagramas de componentes.

Figura 6.19: Representação gráfica de objectos.

Figura 6.20: Objectos com estado.

Figura 6.21: Representação gráfica de objectos activos.

Figura 6.22: Diagrama de classes do Exemplo 6.1.

Figura 6.23: Diagrama de objectos do Exemplo 6.1.


Figura 6.25: Diagrama de classes do Exemplo 6.2, com erros usuais.

Figura 6.26: Diagrama de objectos do Exemplo 6.2.

Figura 7.1: Relações entre diagramas de classes, de objectos e de interacções.

Figura 7.2: Diagrama de interacções.

Figura 7.3: Diferentes representações de mensagens.

Figura 7.4: Exemplo de um diagrama de sequências.

Figura 7.5: Exemplo de um diagrama de colaboração.


Figura 7.7: Diagrama de colaboração de nível de especificação do Exemplo 7.1.

Figura 7.8: Diagrama de colaboração de nível de instâncias do Exemplo 7.1.


Figura 7.10: Diagrama de sequências do Exemplo 7.2.

Figura 7.11: Diagrama de colaboração do Exemplo 7.2.

Figura 7.12: Diagrama de sequências do Exemplo 7.3.

Figura 7.13: Diagrama de colaboração do Exemplo 7.3.

Figura 7.14: Exemplo genérico de diagrama de estados.

Figura 7.15: Diagrama de estados de uma lâmpada.

Figura 7.16: Diagrama de estados da classe Termo.

Figura 7.17: Especificação de acções e actividades num estado.


Figura 7.18: Diagrama de estados de um PC (Exemplo 7.4).

Figura 7.19: Diagrama de estados de um PC, variante 1 (Exemplo 7.4).

Figura 7.20: Diagrama de estados de um PC, variante 2 (Exemplo 7.4).

Figura 7.21: Exemplo genérico de diagrama de actividades.

Figura 7.22: Estados-actividade versus estados-acção.

Figura 7.23: Decisão em diagramas de actividades.

Figura 7.24: Concorrência em diagramas de actividades.

Figura 7.25: Diagramas de actividades com pistas.

Figura 7.26: Diagramas de actividades com objectos.

Figura 7.27: Diagramas de actividades com simbolos para envio e recepção de sinais.

Figura 7.28: Diagramas de actividades da operação de Fibonacci (Exemplo 7.5).

Figura 7.29: Diagrama de actividades da proposta de um termo no GTTI.

Figura 8.1: Representação gráfica de componentes.

Figura 8.2: Componentes e Interfaces.

Figura 8.3: Representação gráfica de nós.

Figura 8.4: Relação entre nós e componentes.

Figura 8.5: Diagrama de componentes do Exemplo 8.1.

Figura 8.6: Diagrama de componentes do Exemplo 8.2.

Figura 8.7: Diagrama de instalação do Exemplo 8.3.

Figura 8.8: Diagrama de instalação (de tipos) do Exemplo 8.4.

Figura 8.9: Diagrama de instalação (de instâncias) do Exemplo 8.4.

Figura 9.1: A Arquitectura do UML a Quatro Camadas.

Figura 9.2: Os pacotes de alto nível do metamodelo UML.

Figura 9.3: Os subpacotes do pacote Foundation.

Figura 9.4: Os classifiers definidos no subpacote Core|Foundation.

Figura 9.5: Os subpacotes do pacote Behavioral Elements.

Figura 9.6: Mecanismos de extensão.

Figura 9.7: Exemplos de estereótipos de classes do perfil de modelação de software.

Figura 9.8: Exemplos de estereótipos de classes do perfil de modelação de negócios.

Figura 9.9: Exemplo de um modelo UML representado em XML.


Lista de Exemplos

Exemplo 5.1: Especificação textual do caso de utilização “Validar Utilizador”.

Exemplo 5.2: Especificação textual do caso de utilização “Obter Extracto de Conta”.

Exemplo 5.3: Especificação textual do caso de utilização “Obter Extracto de Conta” revisitado.

Exemplo 5.4: Especificação textual do caso de utilização “Selecciona Nº de Dias”.

Exemplo 6.1: Diagrama de Classes/Objectos do Sistema de Gestão de Automóveis

Exemplo 6.2: Diagrama de Classes/Objectos do Sistema de Gestão de Compras.

Exemplo 7.1: Diagramas de Colaboração – Pessoa com distintos Papéis.

Exemplo 7.2: Equivalência entre Diagramas de Interacção – Acesso a BD em Java.

Exemplo 7.3: Diagramas de Interacção para descrever Casos de Utilização.

Exemplo 7.4: Diagrama de Estados de um PC.

Exemplo 7.5: Diagrama de actividades da operação de Fibonacci.

Exemplo 7.6: Diagrama de actividades da proposta de um termo no GTTI.

Exemplo 8.1: Diagrama de Componentes relativo a uma Página HTML.

Exemplo 8.2: Diagrama de Componentes relativo à instalação de uma aplicação.

Exemplo 8.3: Diagrama de Instalação do serviço 118 da PT.

Exemplo 8.4: Diagrama de Instalação do Sistema de Trabalho Doméstico .


1. Introdução

Tópicos

§ O Impacto das Tecnologias de Informação§ Produto e Processo§ Objectivos a Atingir§ Problemas com o Software§ Classificações do Software

1.1 O impacto das Tecnologias de Informação

É hoje em dia lugar comum ouvir-se falar da importância que a informática ocupana nossa vida. A rápida evolução e abrangência das tecnologias relacionadascom os sistemas de informação ao longo dos últimos 40 anos tem colocadosucessivos desafios às empresas, e tem mesmo nos últimos tempos posto emcausa modelos tradicionais de fazer negócio. As tecnologias de informaçãopotenciaram o aparecimento de novas indústrias, como sejam as consultorasde sistemas de informação, as relacionadas com a Internet ou a televisão digi-tal, ou reforçaram a importância de outras, nomeadamente as ligadas à indústriade telecomunicações; têm também provocado uma redefinição dasresponsabilidades e das interacções entre os parceiros da cadeia de valor devárias indústrias.

De forma a tirar partido das potencialidades destas tecnologias, é necessárioum grande investimento em software e hardware. Este impacto é visível não sónas grandes organizações de âmbito internacional, mas atinge também aspequenas e médias empresas. O papel das Tecnologias de Informação nasorganizações sofreu diversas alterações; actualmente, as Tecnologias deInformação encontram-se na origem de mudanças significativas ao nível dosmodelos de negócio das empresas e constituem um elemento fundamental paraa obtenção de vantagens estratégicas e competitivas. Por isso, a respectivaimplementação nas organizações deve ser cuidadosamente planificada e


estruturada, de modo a garantir o alinhamento com os objectivos estratégicosdo negócio.

A implementação de sistemas de informação requer um investimento significativo(financeiro, tecnológico e de recursos humanos), pelo que estas intervençõesdeverão merecer o apoio e o comprometimento das administrações. A justificaçãodestes volumes de investimento deve ser efectuada demonstrando qualitativa-mente e quantitativamente o seu valor estratégico e o impacto positivo nas organi-zações.

No entanto, muitos gestores não conseguem perceber o verdadeiro alcance detodas estas tecnologias, quer por questões de formação, quer pela sua anteriorexperiência com sistemas antiquados e obsoletos que constituíam verdadeirosentraves à satisfação dos requisitos do negócio, e não como potenciadores doseu crescimento. Por outro lado, os elementos da área de informática criaramno passado uma imagem muito técnica, pouco alinhada com as reaisnecessidades do negócio o que contribuiu decisivamente para a nãocaracterização da informática como uma área estratégica dentro das empresas.Esta realidade está a mudar (felizmente para todos). Tal facto pode serconstatado de diversas formas:

• no passado era comum que o responsável da informática se encontrassena dependência hierárquica do director financeiro e este reportava àadministração; pelo contrário, actualmente são cada vez menos as empresasem que tal acontece, ficando a área de informática ao mesmo nível que osrestantes departamentos da empresa e reportando directamente ao órgãoque define as respectivas estratégias; a informática passa assim a serconsiderada como uma área estratégica.

• a indústria de software ou de forma mais geral as relacionadas com astecnologias de informação constituem hoje uma das importantes em todo oplaneta, sendo uma das principais responsáveis pelo crescimento contínuoda economia mundial durante a última década; este fenómeno é tambémvisível ao nível das individualidades, já que o homem mais rico do mundo éactualmente um dos principais responsáveis pela maior empresa de soft-ware (estamos obviamente a falar de Bill Gates e da Microsoft);

• a crescente importância das empresas relacionadas com a Nova Economia(que de forma simplificada poderemos associar ao fenómeno Internet)


motivaram a criação de uma bolsa própria (Nasdaq) para transacção dasrespectivas acções;

• a importância destas empresas origina a preocupação dos governos emgarantir o acesso livre ao mercado e a tentar evitar posições monopolistas;é o caso do presente litígio entre o governo americano e a Microsoft, ondeassistimos a disputa de questões por vezes pouco racionais, no entanto eindependentemente da nossa posição pessoal, este governo actua de formaidêntica à de outros predecessores há algumas décadas em relação aempresas de outras indústrias chave como eram a do petróleo e do aço.

Muitos outros exemplos poderiam ser dados, mas a conclusão óbvia é de quenos tornámos dependentes das tecnologias de informação, quer do ponto devista pessoal, quer para a realização das nossas tarefas profissionais; um artigopublicado há não muito tempo revelava que não seria possível às empresasamericanas de maior dimensão sobreviverem se os seus sistemas de informaçãoparassem mais do que um dia.

1.2 Produto e Processo

Esta importância das tecnologias de informação na nossa vida é sobretudoconcretizada pelas funcionalidades que são implementadas ao nível do soft-ware, e que são disponibilizadas com o suporte de um conjunto de dispositivosdiversos (hardware); o primeiro pode ser considerado o componente lógico dossistemas de informação, o segundo representa a parte física.

Não existe uma definição rigorosa e inequívoca de software; diversos autores[Pressman2000, Schach1999] encaram o software como o resultado final deum processo, ao qual designam por Engenharia de Software. O que é um factoé que o software não é dádiva da natureza, nem é objecto de uma produçãonuma linha de montagem, realizada de forma perfeitamente automática, semqualquer intervenção humana, criativa e subjectiva. Podemos pois questionarmo-nos sobre o que distingue verdadeiramente o processo de produção de soft-ware da produção de outros “produtos”.

Quando falamos em processo esta palavra implica desde logo a definição deum conjunto de actividades uniformizadas, a aplicar sistematicamente, que se


encontram agrupadas em fases, cada uma das quais tem os seus intervenientes,com responsabilidades, que possui diversos inputs e que produz outputs. Doponto de vista da garantia da qualidade do produto final (o software) é fundamen-tal que o processo seja realizado segundo parâmetros que permitam tambémaferir a respectiva qualidade, isto é, não conseguiremos optimizar o resultadofinal sem uma preocupação no processo que o produz.

Se pensarmos que o desenvolvimento do software é um processo que deve serbaseado na aplicação de técnicas e práticas rigorosas, sistemáticas, eficientese controláveis, podemos concluir que este se aproxima bastante de outrasrealizações humanas, como a construção de qualquer obra de engenharia civil(por exemplo, a construção da ponte Vasco da Gama em Lisboa). Daí o nomede Engenharia de Software precisamente como tentativa de trazer para estaactividade a preocupação da aplicação de técnicas de engenharia (modelizarantes de realizar; estimar diversos factores antes de avançar; medir antes, du-rante e depois do produto realizado; analisar factores de risco) aodesenvolvimento de software.

Para além dos elementos já descritos, tal como nas outras engenharias tambéma realização efectiva das funções de desenvolvimento de software pressupõe autilização de ferramentas de apoio a todo o processo; o tempo em que odesenvolvimento era efectuado de forma completamente manual já não érazoável actualmente (tal como ninguém constrói uma casa e muito menos umaponte unicamente à custa do seu esforço físico). As características destasferramentas podem ter um impacto apreciável no produto final (bem como noprocesso), e a demonstração desse facto é um dos objectivos deste livro.

No entanto, é também importante esclarecer desde já que a produção de soft-ware tem em si mesma alguma subjectividade, devido ao facto de ser realizadapor seres humanos, que em diversos pontos podem introduzir factoresresultantes da opinião pessoal (e que até certo ponto podem ser benéficos, poisa criatividade pode levar à produção de software com melhor desempenho);neste ponto, o processo aproxima-se mais de uma Arte do que propriamente deEngenharia. É por isso que diversos autores consideram que o ponto de equilíbriocorrecto depende de cada caso, mas deve-se encontrar a meio caminho entre aaplicação de técnicas estruturadas (Engenharia) e introdução de factores decriatividade (Arte).


1.3 Objectivos a atingir com o desenvolvimento de software

Ao longo do tempo, o papel do software e dos sistemas de informação nasorganizações tem evoluído de forma a posicionar-se cada vez mais como factorestratégico e competitivo das organizações. Nos primórdios da computação (oque já parece há muito tempo, mas estamos a falar de algo que ocorreu à cercade 60 anos atrás) o software era utilizado sobretudo para a resolução deproblemas de cálculo relacionados com questões militares (por exemplo, cálculoda trajectórias de projectéis). Só durante a década de 50 é que começaram asurgir os primeiros computadores com aplicações comerciais, utilizados pelasgrandes organizações com o objectivo de automatizar alguns processos denegócio (ou algumas das suas etapas) e desta forma de reduzir custos. A partirdeste momento a importância dos sistemas de informação nas organizaçõesnão tem parado de crescer, e podemos caracterizá-la resumidamente de acordocom o apresentado no gráfico seguinte.

Outras classificações foram elaboradas, nomeadamente a de Primozic, queidentifica 5 grandes ondas de inovação, de acordo com a evolução das tecnologiasde informação e os benefícios crescentes que oferecem às organizações.

1970 1980 1990 2000

Computação MainframeProcessamento Batch

Sistemas DepartamentaisProcessmanto OnlineBases de Dados relacionais

Redução de Custos

utomatização Autonomizaçãodo Utilizador

VantagemCompetitiva

Driver doNegócio

Computador PessoalFerramentas de Produtividade Pessoal

Tecnologias O-OSuporte à decisãoGestão do conhecimento

InternetComputação Ubiqua


Tabela 1.1 – Ondas de Inovação de Primozic

Independentemente destas classificações, existe um conjunto de razões quepode levar as organizações a investir em sistemas de informação e que podemosindicar de seguida:• reduzir custos operacionais, através da automatização e reformulação dos

processos de negócio;• satisfazer requisitos de informação dos utilizadores;• contribuir para a criação de novos produtos e serviços;• melhorar o nível de serviço prestado aos clientes actuais, e atingir outros

potenciais;• melhorar e automatizar a relação com os parceiros de negócio.

1.4 Problemas com o Software

Historicamente, o software tem apresentado de forma sistemática e continua osmesmos problemas. As razões que no passado justificaram a adopção demétodos de trabalho mais estruturados continuam a verificar-se e por isso somoslevados a concluir que estas iniciativas então confidenciais afinal não vieramresolver de todo os problemas. Se pensarmos no impacto na organização, estespodem ser essencialmente agrupados em três níveis:• falta de qualidade, traduzida na satisfação incompleta dos requisitos, nos

problemas que se verificam após a instalação do produto;


• desvios dos prazos previamente estabelecidos para o desenvolvimento desoftware;

• custos previamente definidos para o desenvolvimento de software sãolargamente ultrapassados.

O quadro seguinte permite ilustrar que ao longo do tempo diversos problemastêm existido de forma contínua, e independentemente das iniciativas que temosdesenvolvido, estas não eliminarem de forma nenhuma o problema.

Tabela 1.2 – Estatísticas diversas obtidas ao longo do tempo sobre os projectos de

desenvolvimento de software


Foi precisamente este tipo de problemas que motivou a designação de “crise nosoftware” já durante a década de 70, a qual foi reforçada por Fred Brooks[Brooks86] no seu célebre artigo “No Silver Bullet” de1986 (não existem balas deprata), no qual este refere que dificilmente se encontraria uma cura milagrosaque pudessem resolver os problemas associados ao processo dedesenvolvimento de software.

Os problemas até agora referidos têm muito a ver com questões que se verificamdurante o processo de desenvolvimento do software, mas igualmente gravessão as situações que podem ocorrer depois deste processo estar concluído, eos sistemas entrarem em produção. Neste caso, o adequado funcionamentodos sistemas é crucial para a existência e sobrevivência das organizações edas pessoas envolvidas, a diferentes níveis, envolvendo questões económicas,de segurança, privacidade, qualidade de vida, etc. Existem diversos casosclássicos que apontam para as falhas do software em funcionamento:

• em 1979, ainda durante o período da guerra-fria, o mundo pode ter estado àbeira de uma guerra nuclear quando o sistema americano que controlava oespaço aéreo detectou o lançamento de mísseis pela União Soviética emdirecção aos Estados Unidos; de facto, tratava-se de um ataque simulado, eapesar de não terem sido divulgados muitos detalhes, parece legítimo suporque tal se tratou de um erro de detecção pelo sistema;

• durante a guerra do Golfo, uma falha no software dos mísseis Patriot que osEstados Unidos enviaram para a zona da guerra não foi atempadamentedetectada, e a correcção só chegou um dia após um ataque iraquiano commísseis ter causado a morte a cerca de trinta soldados americanos;

• devido a um erro no software de controlo de um equipamento médico, pelomenos dois doentes morreram entre 1985 e 1987 em consequência de teremrecebido doses exageradas de radiação;

• problemas diversos no software de controlo da distribuição e encaminhamentode bagagem do aeroporto de Denver provocaram custos de 1 milhão USDpor dia;

• estimativas não oficiais apontam para custos de cerca de 400 milhões delibras quando a bolsa de Londres decidiu abandonar o desenvolvimento dosistema de informação Taurus, devido a vários problemas;

• em 1995, estimativas diversas apontavam para que o custo dos projectosde software que foram abandonados nos Estados Unidos equivaleria a cercade 80 mil milhões USD, qualquer coisa como 1% do PIB americano.


Como se pode constatar dos exemplos anteriores, os problemas resultantes domau funcionamento ou do processo de desenvolvimento de software podem terimpacto em duas áreas críticas: questões financeiras por um lado, e vidashumanas por outro.

Mesmo após a entrada em funcionamento do software, poder-se-ia pensar queo número de problemas iria diminuir drasticamente e estabilizar num nível muitobaixo, próximo de 0. Tal de facto não acontece, e qualquer intervenção que sejarealizada pode motivar um conjunto de problemas não previstos, econsequentemente um acréscimo de erros.

1.5 Classificações do Software

Diversas classificações sobre software existem actualmente, sendo que cadauma realça determinadas características do mesmo para proceder à suacategorização.

Talvez a classificação mais antiga elaborada tenha a ver com o nível dentro daorganização no qual o software tem impacto: estratégico, táctico e operacional.Esta classificação foi elaborada por Anthony em 1965 e ainda hoje continua aser válida.

Tabela 1.3 – Exemplos de sistemas segundo a classificação de Anthony


Outra classificação muito referida na literatura tem a ver com o tipo de utilidadedo software, e que agrupa o software nas seguintes categorias:

• software de sistema: inclui todos os programas cujo objectivo é disponibilizarfuncionalidades a outros programas; por exemplo, sistemas operativos,sistemas de gestão de bases de dados, servidores de correio electrónico,ferramentas de desenvolvimento, compiladores, etc.;

• software de gestão: inclui todos os programas cujo objectivo é suportar asnecessidades de informação e as funcionalidades das várias organizações;inclui programas para indústrias específicas (bancos, seguradoras, indústriade processos, etc.), numa perspectiva vertical, ou aqueles que têm a vercom áreas horizontais e comuns à generalidade das organizações(contabilidade, tesouraria, gestão de recursos humanos, gestão de stocks);

• software científico: agrupa todo o software que se destina a apoiarnecessidades específicas das organizações que se dedicam à investigação;normalmente estamos a falar de sistemas com algoritmos de cálculo muitoelaborados, e que necessitam do suporte de máquinas poderosas.

Podemos ainda identificar um conjunto de outras categorias referidas na literatura:

• software de tempo real: destina-se a controlar diversos dispositivos e emque a importância de responder a determinados eventos se revela importante;

• embedded software: trata-se de software que vem já “agregado” a algunsdispositivos electrónicos quando são adquiridos, e que lhes conferem alguma“inteligência” (por exemplo, vídeos, televisões);

• software de inteligência artificial: software que utiliza um conjunto dealgoritmos que tenta imitar o modelo de raciocínio humano para determinara solução para alguns problemas; tem tido aplicação em áreas como aelaboração de diagnósticos médicos, recomendações sobre investimentos,e inclui os sistemas especialistas ou periciais, redes neuronais,reconhecimento de padrões;

• software para computador pessoal: inclui todo o software que éespecificamente desenvolvido para ser utilizado num computador pessoal,e que vai desde o sistema operativo, aos processadores de texto, folhas decálculo, etc.

No segundo capítulo será apresentada uma outra classificação do software,após a definição do conceito de sistema de informação.


Independentemente da classificação, não faz sentido colocar um sistematotalmente numa categoria, mas sim encará-lo como dispondo de funcionalidadesde uma das categorias apresentadas.

UML - Processos e Ferramentas CASE · que é o UML (Unified Modeling Language), como aplicar o UML...

Documents

Transcript of UML - Processos e Ferramentas CASE · que é o UML (Unified Modeling Language), como aplicar o UML...