Escolar Documentos
Profissional Documentos
Cultura Documentos
2.5.2. Planeamento
Alguns autores não consideram no âmbito da Engenharia de Software. Outros consideram-na
como transversal. A nossa perspectiva é que só temos um projecto depois do seu plano estar
aprovado, e é esse o objectivo dessa tarefa.
Existem várias circunstâncias particulares em que esta tarefa deve ser efectuada:
- Num projecto que envolve a selecção de entidades para posterior implementação do software, a
elaboração de cadernos de encargos e a avaliação de propostas
- Apenas investigação inicial
A grande preocupação desta fase é que a partir de um levantamento de alto nível das
necessidades do negócio seja possível elaborar um plano de projecto. Para isso existem um
conjunto de actividades que deverão ser realizadas:
- Compreender a missão e organização da empresa
- Identificar e envolver todos os interessados e afectados pela introdução do sistema
- Obter uma visão de alto nível do funcionamento do sistema actual (caso exista)
- Definir o âmbito do sistema
- Elaboração de uma descrição de alto nível do problema
- Identificar restrições, problemas e riscos do projecto
- Identificar alternativas de implementação, avaliá-las e seleccionar
- Apresentar resultados e recomendações, com justificação técnica funcional e financeira
- Elaborar e obter aprovação de um plano de projecto
- Definir o processo de controlo do projecto
O principal output desta tarefa será um plano de projecto, que deverá reflectir sustentadamente a
visão que se tem nesta fase.
2.5.3. Análise
Efectua o estudo detalhado do domínio do problema, e culmina na elaboração de um documento
onde os requisitos funcionais da solução a implementar e outras questões relevantes (restrições,
âmbito, fluxos de informação) são enumerados. Tem, normalmente dois grandes momentos ou
sub-tarefas (realizados em simultâneo):
- Levantamento de Requisitos
Um requisito é uma funcionalidade ou condição que o sistema deverá possuir. Reuniões,
observações, protótipos,...
- Especificação do Sistema
Não é tarefa fácil. As interpretações são subjectivas. O objectivo geral desta subtarefa é expressar
sem ambiguidades o que os sistema deve fazer e não como fazer o sistema.
A “Especificação de Requisitos” é um documento que deve ser visto como um contrato.
2.5.4. Desenho
Pretende efectuar a definição do domínio da solução, com base na análise. Procede-se à
especificação formal ou informal das características que a implementação do sistema deverá
apresentar. Inclui arquitectura de computadores, tecnologias de bases de dados, etc., bem como
ambiente e linguagem de programação a usar.
Diz-se por vezes que é a fase de especificação técnica pois aqui se definem componentes
aplicacionais, tecnológicos e dados.
Factores como o desempenho, a segurança e a operacionalidade, custos e prazos, deverão se
critérios para seleccionar alternativas. Planos de testes e de migração deverão ser previstos.
2.5.5. Implementação
É a concretização do modelo do desenho.
Os componentes aplicacionais são codificados e testados de forma isolada (testes unitários).
Actualmente assiste-se, no contexto dos sistemas de informação cliente/servidor, à crescente
utilização de ambientes de desenvolvimento bastante produtivos (designados por ambientes RAID
– Rapid Application Development), baseados em infra-estruturas de objectos/componentes
evoluídos, complexos e providenciando paradigmas de prototipagem de desenvolvimento visual
(ex. ferramentas CASE).
Cada vez mais as organizações compram produtos previamente desenvolvidos mais ou menos
uniformizados funcionalmente (pacotes), o que levou a que a programação pura cedeu uma parte
da sua importância em favor de esforços de integração (entre os diverso componentes “pré-
fabricados”), sua parametrização e configuração.
2.5.6. Testes
Os testes deverão ser executados em condições idênticas aquelas que o sistema real irá possuir.
Podem ser classificados em diferentes categorias, segundo as características do sistema que
avaliam:
- Testes de carga: avaliam o sistema perante a utilização intensiva e aferem as capacidades de
escalabilidade
- Testes de desempenho: Analisam o tempo de resposta do sistema e verificam o nível de
utilização dos recursos disponíveis
- Testes de usabilidade: analisam a adequabilidade do desenho das interfaces homem-máquina
- Testes funcionais: se os requisitos são satisfeitos
Outra classificação é segundo o âmbito dos componentes do sistema:
- Testes unitários
- Testes de integração
- Testes de sistema
- Testes de aceitação
No caso de substituição de sistemas muitas vezes usa-se a estratégia do paralelo de sistemas
(repetição das actividades do antigo sistema, no novo).
A verificação deve ser acompanhada a diferentes níveis por ferramentas de debugging.
2.5.7. Instalação
Envolve um conjunto de tarefas:
- Configuração e parametrização do sistema
- Instalação dos componentes aplicacionais necessários
- Definição de perfis, de utilizadores e de níveis de segurança
- Formação dos utilizadores do sistema
- Elaboração de documentação de operação, administração e utilização do sistema
- Definição e implementação de políticas de segurança (ex. backups)
2.5.8. Manutenção
Com o tempo aparecem os bugs, para além de solicitações externas e internas relativamente a
pedidos de alteração de requisitos.
Novos requisitos (60%); Erros (18%); Melhorias (18%).
É possível ver a tarefa de manutenção desencadeia uma nova iteração de todo o processo.
Stradis (Strutured analysis, design and implementation of information systems). Gane e Sarson
nos finais da década de 70, baseada na filosofia de decomposição funcional top-down e suportada
essencialmente pela utilização de diagramas de fluxo de dados.
Engenharia de Informação
James Martin em 1989. Integra muitos conceitos das outras.
Ao contrário das outras tem uma preocupação estratégica com a definição dos sistemas de
informação, o que é expresso nos diferentes estágios de evolução do processo: planeamento
estratégico; análise de áreas de negócio; desenho de sistemas; implementação.
realização
-------------------|>
dependência
------------------>
transição de estado
_____________________>
generalização
_____________________|>
Estereótipos
É um metatipo. Permite definir novos tipos de elementos sem se alterar o metamodelo do UML «»
A definição de um estereótipo tem de ter em conta os seguintes aspectos:
- Propriedades (pode providenciar o seu próprio conjunto de marcas)
- Semântica (pode providenciar as suas próprias restrições)
- Notação (pode providenciar o seu próprio ícone)
- A classe base do metamodelo, que vai ser estendida
Restrições (constraints)
Permitem adicionar ou alterar a semântica assumida por omissão de qualquer elemento UML.
{ } A condição pode ser especificada numa linguagem formal ou informal.
Importação e Exportação
Um pacote faz a exportação, por definição, de todos os seus elementos públicos. mas tal facto
não implica que um elemento definido noutro pacote possa aceder/referenciar um elemento
exportado num outro pacote. Para que tal acontecesse deveria existir explicitamente uma relação
de importação entre esses dois pacotes.
A relação de importação é uma relação de dependência entre pacotes, especificando que o
pacote base importa todos os elementos públicos definidos no pacote destino. É representada por
uma linha dirigida, a tracejado, com estereótipo «import». Não é transitiva. Não é simétrica.
Preferencialmente, os elementos exportados por cada pacote devem ser do tipo interface.
Generalização
É semelhante à homóloga existente entre classes, e é usada para especificação de famílias de
pacotes, típicas em sistemas complexos ou flexíveis (significativamente parametrizáveis, multi-
plataforma, multi-linguagem). Permite especializar pacotes.
Extensão («extend»)
O caso base incorpora implicitamente o seu comportamento num local especificado
indirectamente pelo caso que é usado. Ou seja, o caso destino pode ser estendido com o
comportamento de outro(s) caso(s). Permite representar:
- A parte de um caso que um utilizador vê como opcional, ou como existindo várias alternativas
- Um subfluxo de acções que é executado apenas se determinadas condições se verificarem
- Vários fluxos de acções que podem ser inseridos num determinado ponto de extensão, de forma
controlada, através de uma interacção explícita com um actor.
O caso de utilização de destino é estendido num ou mais pontos (pontos de extensão), ou seja
são pontos de entrada do caso de utilização que lhe dá algum nível de configurabilidade e
versatilidade.
Ex. escolher nº de dias no Obter Extracto de Conta.
Textual: Nome: Obter Extracto de Conta; Pontos de Extensão: Nº de Dias; Cenário Principal;
Cenário Alternativo 1.
5.3.1. Actores
É o conceito que representa, em geral mas nem sempre (ex. outro sistema informático, hardware,
ou tempo), um papel que um utilizador desempenha relativamente ao sistema em análise.
6.2. Classes
É a descrição de um conjunto de objectos que partilham os mesmos atributos, operações,
relações e a mesma semântica. Corresponde a algo tangível ou a uma abstracção conceptual.
É representada por um rectângulo, com uma, duas ou três secções.
Na 1ª - nome da classe; na 2ª - lista de atributos; 3ª - lista de métodos.
Opcionalmente pode ter 4ª - outra informação (ex. lista de responsabilidades que a classe
assume)
O nome pode vir na forma simples ou completa ( pacote::nome).
Os atributos podem ter apenas o nome ou, adicionalmente, os respectivos tipos, visibilidade e
outras qualificações.
visibility name [multiplicity] : type-expression = initial-value {property-string}
A multiplicidade por omissão é 1..1 (exactamente 1).
Nas operações (métodos) podem ver-se só os nomes ou também as assinaturas, visibilidade,
outras qualificações (ex. abstracta ou polimórfica).
visibility name (parameter-list) : return-type-expression {property-string}
Podem definir-se subsecções dentro da 2ª ou 3ª secções de forma a organizar melhor, com base
na noção de estereótipo.
6.3. Relações
Estabelece a ligação entre elementos e é representada graficamente por um determinado tipo de
linha. Os 3 tipos de relações mais importantes são:
- Dependências
- Generalizações
- Associações
Multiplicidade
Traduz o nº de instâncias de uma classe que se podem relacionar com uma única instância da
outra.
muitos (*); um ou mais (1..*), exactamente 1 (1), zero ou um (0..1), determinado nº (3),
determinada gama (2..6) ou listas (0..3,5..7,10..*)
Navegação
Traduz a forma como a partir de uma instância de uma classe se pode aceder a uma ou mais
instâncias de outra classe relacionada pela associação. Por omissão é bidireccional. Mas pode
interessar ser unidireccional (ex: utilizador e password).
Agregação (Simples)
Traduz que existe uma relação do tipo “is-part-of” ou “has-a”, isto é, uma instância de uma dada
classe possuir ou ser composta por várias instâncias de outra classe. O adorno é um losango
junto do elemento agregador ou “o todo”. Ex: PC e CPU, teclado, ...
Associações Qualificadas
Um qualificador é um atributo (da associação), ou lista de atributos, cujos valores servem para
partir o conjunto de instâncias associadas a uma instância ao longo de uma associação.
É representado por pequeno rectângulo junto do extremo de uma associação. É colocado no
extremo da classe origem da associação.
Uma instância da classe de origem, conjuntamente com um valor do qualificador, permite
seleccionar univocamente um subconjunto das instâncias da classe destino. A multiplicidade
afecta o extremo destino. Os valores comuns são: 0..1 1 * . Ex. Banco (qualificador – nº
conta) e Pessoa; Tabuleiro Xadrez – linha/coluna --> Quadrado.
Associações Reflexivas
Quando estabelece uma relação estrutural consigo própria. Acontece quando uma classe tem
objectos que desempenham diferentes papéis. ex. ocupante do carro : condutor e passageiro.
Classes-Associação
A associação pode também ter os seus próprios atributos (e eventualmente operações), devendo
por conseguinte ser modelada também como uma classe. Ex. classe-associação Tarefa que é
traduzida da associação entre pessoa e empresa. Representa-se por linha a tracejado a ligá-la à
linha da associação.
6.4. Interfaces
É um contrato na forma de uma colecção de especificações de métodos que providencia um
mecanismo para separação clara entre a vista externa e a interna de um determinado elemento.
É realizada ou implementada por uma ou mais classes.
Este conceito apresenta os seguintes benefícios ao nível de programação:
- Captura de semelhanças entre classes não relacionadas
- Declaração de métodos que uma ou mais classes esperam implementar
- Um objecto pode ser visto de diferentes perspectivas (diferentes tipos) consoante as
circunstâncias.
Representação Gráfica
Como uma classe mas com o estereótipo «interface». Alternativamente pode ser um círculo.
Operações
Os objectos podem efectuar operações definidas nas suas classes. ex: fac.CalculaIvaTotal()
Estado
O estado de um objecto é dado pelos valores assumidos pelo conjunto de atributos de um objecto.
É dinâmico e até pode ser associado a máquina de estados.
termo:Termo ar:Docente
Objectos Activos
Ex. são Processos, fluxos de execução, agentes de software e aplicações, que apresentam uma
visão da dinâmica de um sistema. Têm a particularidade de terem controlo sobre o seu próprio
fluxo de execução. Representam-se com linhas de maior espessura.
Objectos Compostos
É constituído por outros (sub)objectos. Em geral reflectem relações de agregação. São
representados como objectos normais, com a excepção dos seus atributos serem substituídos por
outros objectos, usando sublinhado ou através de uma representação gráfica. A vantagem é de
maior clareza e simplicidade dos diagramas produzidos.
0..1 * 0..1 1
Veiculo Motor
Pessoa
modelo
matrícula numero
cor cilindrada
combustível
CAP. 7 – UML – MODELAÇÃO DO COMPORTAMENTO
7.1. Introdução
Em qualquer sistema minimamente interessante, os objectos não estão estáticos, mas interagem
entre si por troca de mensagens.
A modelação do comportamento de um sistema de software consiste em 2 tipos distintos de
especificações:
- Modelação do comportamento interobjectos (diagramas de interacção)
- Modelação do comportamento intra-objecto, ou seja na identificação dos estados em que o
objecto pode estar ao longo do seu ciclo de vida, dos eventos envolvidos, ebm como dos seus
algoritmos (diagramas de estados e actividades)
O UML providencia os seguintes elementos, que permitem a especificação do comportamento
dum sistema:
- objectos
- interacções
- mensagens
- estados
- eventos
- sinais
- actividades
7.2. Interacções
É a especificação do comportamento de um conjunto de instâncias, representado pela sua troca
de mensagens, num determinado contexto, e com vista à concretização de um objectivo.
As interacções são usadas para modelar o fluxo de controlo de uma operação, classe,
componente, caso de utilização ou sistema na sua globalidade. Sempre que existe uma ligação
(link) entre instâncias, pode ocorrer uma ou mais interacções.
Uma mensagem define uma comunicação particular entre instâncias.
Expls de comunicações:
- invocar uma operação;
- lançar um sinal;
- construir ou destruir uma instância
A mensagem especifica não só o tipo de comunicação mas também os papéis do emissor e do
receptor, a acção lançada e o papel da ligação.
7.4.1. Estados
É uma situação registada por um objecto durante o seu respectivo ciclo de vida, durante a qual
uma condição é verificada, vai executando alguma actividade, ou simplesmente espera que
determinado evento ocorra.
Um estado tem diferentes partes:
- Nome. Sem nome é anónimo
- Acções de Entrada e de Saída
- Transições Internas
- Sub-Estados (disjuntos, isto é, sequencialmente activos, ou concorrentes)
- Eventos Deferidos: não são tratados no estado corrente
7.4.2. Transições
É uma relação entre 2 estados que especifica que um objecto que se encontre no primeiro estado,
realizará um conjunto de acções e mudará para o segundo estado quando um determinado
evento ocorrer e determinadas condições se verificarem.
É descrita pela sintaxe:
evento [condição com guarda] / acção
Tem diferentes partes:
- O estado de origem e o estado de destino
- Evento de Gatilho
- Condição de Guarda: expressão lógica
- Acção
Podem existir transições sem gatilho, quando o estado origem termina a sua actividade
normalmente. Pode ter múltiplos estados de origem (concorrentes)
7.4.3. Eventos
É uma ocorrência de um estímulo que pode corresponder a uma transição de estado. Há 4 tipos:
- Sinais
- Invocação
- Passagem do tempo
- Mudança de estado
Um sinal representa um objecto com nome que é enviado (lançado) assincronamente por um
objecto e recebido (apanhado) por outro. Ex. mecanismo de excepções das linguagens.
Um evento de invocação corresponde ao lançamento de uma operação tipicamente de modo
síncrono.
A representação gráfica é igual mas o sinal é tratado pela própria máquina de estados e a
invocação por um método.
O evento passagem de tempo é assinalado no diagrama pela palavra after seguida de uma
expressão, embora possa não se explicitar.
O evento mudança de estado representa uma mudança de estado ou satisfação de determinada
condição e modeliza-se pela palavra-chave when seguida de expressão lógica.
7.5.1. Decisões
A tomada de decisão é um mecanismo comum aos DE e DA que consiste em especificar que
actividade deve ser realizada após a execução da actividade corrente, dependendo de uma
condição de guarda.