Software

14-03-2012

Bases de Dados

Paulo Azevedo

Objectivos
• Aquisição de um processo simplificado de
desenvolvimento de soluções de software,
baseada na utilização da notação UML e
técnicas associadas.

Paulo Azevedo - Fev/2012 2

1

14-03-2012

Produção de software
• A produção de software é frequentemente
uma actividade não estruturada, sem
orientações de natureza estratégica e sem
planos de gestão e controlo;
• Os problemas associados ao desenvolvimento
de software são tão complexos que é
necessário a utilização de princípios, regras e
estratégias que conduzam a melhorias.


• Definir o tipo de intervenção e conjugar
correctamente as interacções entre as
pessoas, o processo aplicado, as
características do produto e o projecto que
orienta as actividades a desenvolver.
• Regra dos quatro “P’s”.


2

14-03-2012

Regra dos quatro “P’s”:
– Pessoas – Só com Motivação e compromisso é que
se consegue garantir o sucesso;
– Processo – Com técnicas e regras bem definidas;
– Produto – Compreendendo as necessidades reais
dos utilizadores obtemos um resultado com
qualidade;
– Projecto – Deve ser credível e controlado para
cumprir prazos e custos propostos


Um projecto de sistemas de informação deve
responder – W5H2 (Barry Boehm 1996):
– Porque é que vai ser desenvolvido WHY;
– O que vai ser feito/deve ser feito WHAT;
– Quando é que vai ser feito WHEN;
– Quem é o responsável WHO;
– Onde estão as responsabilidades WHERE;
– Como é que vai ser feito HOW;
– Quanto vai custar HOW MUCH.


3

14-03-2012

Processo de desenvolvimento de sw é uma
sequência de actividades, agrupadas em fases,
executadas de forma sistemática e
uniformizada, realizadas por intervenientes
com responsabilidades definidas em que a
partir de um conjunto de entradas se
produzem um conjunto de saídas. Tem quatro
objectivos fundamentais.


Objectivos do Processo de desenvolvimento
de sw:
1. Providenciar orientação sobre a sequência de
realização das actividades;
2. Especificar modelos descritivos do sistema
que devem ser desenvolvidos;
3. Dirigir tarefas dos participantes e da equipa;
4. Providenciar critérios para monitorização e
avaliação dos modelos.

4

14-03-2012

Metodologias de desenvolvimento de sw
sequência de etapas e procedimentos
recomendados para serem aplicados durante
o processo de desenvolvimento de SI.
Acrescenta a utilização de um conjunto de
ferramentas, técnicas e notações.
Inclui referências a princípios e regras para
concretizar na prática regras teóricas


Princípios Metodologias de desenvolvimento sw:
• Elaborar estimativas (custos/prazos);
• Técnicas para efectuar medições;
• Procedimentos para garantir qualidade;
• Programas de formação;
• Modelos de documentação a produzir;
• Modelos práticos;
• Técnicas para configuração de metodologia.

5

14-03-2012

Um modelo consiste na interpretação de um
dado domínio do problema, segundo uma
determinada estrutura de conceitos.
Um esquema é a especificação de um modelo
usando uma determinada linguagem, formal
ou informal. A representação gráfica de um
esquema é um diagrama.


A modelação é a arte e a ciência de criar
modelos de uma determinada realidade.
Técnica aceite pela generalidade das
disciplinas conhecidas. Permite a partilha de
conhecimento entre grupos intervenientes.


6

14-03-2012

Benefícios da modelação:
• Modelos ajudam a visualizar um esquema;
• Permitem especificar a estrutura ou
comportamento de um sistema;
• Controlar e guiar o processo de construção do
sistema;
• Documentam decisões tomadas.


A Evolução das técnicas e metodologias de
modelação divide-se em duas fases (Rumbaugh,
1996):

1. Aproximação estruturada ou funcional;
2. Aproximação baseada no paradigma dos
objectos.


7

14-03-2012

Aproximação estruturada ou funcional:
• Diversidade de autores propõem abordagens
especificas e nomenclaturas distintas para a
modelação de sistemas de informação;
• Grande diversidade de propostas tornava
difícil a comunicação e reduzia a utilidade
prática desta área de conhecimento;


Aproximação estruturada ou funcional (cont.):
• Diferenças nos modelos semânticos, notação
sintáctica e diagramas originaram uma
proposta unificadora;
• SSADM, Yourdon.


8

14-03-2012

SSADM:
• Metodologia de referência e ensinada em
diversos cursos universitários;
• Diagramas de Fluxos de Dados;
• Diagramas Entidade Relação;
• Diagramas de Ciclo da Vida das Entidades;
• Focada na análise e desenho do sistema, não
contempla tarefas relacionadas com a
implementação.


Yourdon:
• Baseada da filosofia da decomposição
funcional (top down);
• Suportada na utilização de DFD;
• Recorre muito à decomposição funcional;
• Atribui importância significativa à estrutura de
dados.


9

14-03-2012

Aproximação baseada no paradigma dos
objectos:
• Notação padronizada, constituída por um
conjunto limitado de elementos que podem
ser tipificados em diagramas, abstracções e
relacionamentos.


Booch, Jacobson e Rumbaugh iniciaram um
trabalho para apresentar uma proposta
unificadora dos seus trabalhos individuais.
Este trabalho deu origem ao UML (Unified
Modelling Language), apresentado
publicamente em Outubro de 1995.
Em Novembro de 1997 a UML foi adoptada
pela OMG como linguagem de modelação
padronizada.


10

14-03-2012

Contribuições para o UML:

V 1.0 V 1.4 V 2.0
1997 2001 2004
Wirfs-Brock Coad-Yourdon Gamma et al. Wirfs-Brock
1990 1991 1995 1997

UML

Shlaer-Mellor Rumbaugh Booch Jacobson
1989 1991 1994 1995

V 1.3 V 1.5
1999 2003


Actualmente na versão 2.0.
Esta versão demonstra um grau de
maturidade da linguagem, utilizando
princípios da meta-modelação para definir os
conceitos do UML através da própria
linguagem.


11

14-03-2012

UML


UML
• Resultado de um longo processo de maturação
no domínio da modelação.
• Fornece uma linguagem universal para
especificação de software.
• A utilização da notação UML deve ser
enquadrada pela adopção de um processo que
estruture o trabalho de desenvolvimento:
– O que deve ser feito;
– Como deve ser feito, como fazer (técnicas a utilizar).


12

14-03-2012

UML
• Um modelo UML é constituído por um conjunto
de diagramas que representam aspectos
complementares de um SI.
• Em cada um destes diagramas são utilizados
símbolos que representam os elementos que
estão a ser modelados (abstracções) e linhas que
relacionam esses elementos.
• Os símbolos e as linhas têm significado especifico
e possuem formas distintas, constituindo um
modo de notação.

UML - Diagramas
O UML disponibiliza o seguinte conjunto de diagramas:
1. Diagrama de Use Cases;
2. Diagrama de Classes;
3. Diagrama de Objectos;
4. Diagrama de Sequência e Diagrama de Colaboração;
5. Diagrama de Actividade;
6. Diagrama de Estados;
7. Diagrama de Componentes;
8. Diagrama de Instalação


13

14-03-2012

UML – Diagrama de Use Cases
Serve para identificar as fronteiras do sistema
e descrever os serviços (use cases) que devem
ser disponibilizados a cada um dos diversos
utilizadores (actores).


UML – Diagrama de Classes
Através do qual descrevemos a estrutura da
informação (classes e suas relações) que é
utilizada no sistema.


14

14-03-2012

UML – Diagrama de Objectos
Utilizado para ilustrar um diagrama de classes
com um exemplo concreto.


UML – Diagrama de sequência e
colaboração
Ilustram como os objectos do sistema
interagem para fornecer a funcionalidade do
use case. Estes diagramas designam-se
genericamente por diagramas de interacção.


15

14-03-2012

UML – Diagrama de Actividade
Pode ser utilizado para descrever cada um dos
use cases, realçando o encadeamento de
actividades realizadas por cada um dos
objectos do sistema, numa óptica de fluxo de
trabalho.


UML – Diagrama de Estados
Utilizado para modelar o comportamento dos
objectos, isto é, descrever as alterações nos
valores de atributos dos objectos em
resultado da ocorrência de certos eventos .


16

14-03-2012

UML – Diagrama de Componentes
Utilizado para descrever a arquitectura da
aplicação informática em termos de
componentes de software


UML – Diagrama de Instalação
Permite descrever a arquitectura de
equipamento informático utilizado e
atribuição dos componentes da aplicação aos
diversos equipamentos.


17

14-03-2012

UML
• Métodos que se baseiam na utilização da
notação UML:
– Rational Unified Process (RUP), da Rational
2

Software, por Philippe Kruchten, Ivar Jacobson e
outros;
– Extreme Programming (XP), por Kent Beck e
3

outros;
– Feature Dreaven Development (FDD), por Peter4

Coad;


UML
• No projecto de desenvolvimento que aqui
exploramos, vamos utilizar um Processo
Simplificado. O objectivo não é discutir um
Processo completo e com alguma
complexidade, mas mostrar a aplicação da
UML de uma forma ágil e consequente.


18

14-03-2012

Modelação de software
• Um projecto de desenvolvimento engloba três
grandes etapas (ver figura):
– Análise da Organização (análise estratégica,
levantamento de requisitos, etc.);
– Especificação do sistema de software que responda às
necessidades identificadas;
– Implementação e instalação da solução
Processo de desenvolvimento

Análise do Especificação do
Implementação
negócio sistema de SW

Técnicas; Técnicas; Técnicas;
Instrumentos; Instrumentos; Instrumentos;
Ferramentas. Ferramentas.
Paulo Azevedo - Fev/2012 Ferramentas. 37

Exemplo
Implementar um mini-projecto para a gestão
de um ponto de venda de uma loja. O
problema pode ser formulado nestes termos:
“A empresa ABC necessita de um sistema
informático para registar as vendas, que têm
lugar na loja, ao consumidor final, assim como
os respectivos pagamentos.”
Sabemos o que queremos fazer! Mas, por
onde começar?


19

14-03-2012

Ciclo de vida
• Preparar - investigar a área do problema e fixar
os requisitos e âmbito da solução;
• Construir - analisar o problema, e construir
modelos abstractos de resolução. Destes
modelos, evoluir para especificações lógicas da
solução pretendida e, finalmente, implementar
numa linguagem de programação.;
• Instalar - transferir a solução para os ambientes
reais de produção.

Ciclo de vida

Preparar Construir Instalar

Compreensão do problema; Modelos de Análise e Transferência para
Requisitos e âmbito do Desenho; ambiente de produção
sistema; Protótipo operacional.
Plano de projecto.


20

14-03-2012

Fase 1 - Panorâmica
A fase Preparar envolve actividades para as
quais não é particularmente importante ser
versado em competências "Orientadas ao
Objecto". O principal objectivo é identificar
claramente quais são os requisitos do sistema
a desenvolver de modo a suportar o
planeamento, avaliação do risco e benefícios,
bem como colher o compromisso de avançar
junto do “cliente”.

Fase 1 – Definir requisitos
A análise de requisitos é uma disciplina só por
si, para além do âmbito deste texto. A bem da
simplicidade, vamos abreviar e avançar uma
listagem informal de requisitos. No nosso caso
de estudo, vamos limitar-nos ao processador
de texto Microsoft Word. Verdadeiramente
importante é que neste processo não sejam
omitidos requisitos!


21

14-03-2012

Fase 1 – Definir requisitos
Empresa ABC
1 – Propósito
-…
-…
2 – Objectivos
-…
-…
3 – Cliente
-…
4 – Requisitos funcionais
-RF1
-RF2
5 – Atributos do sistema
Performance; Interfaces


Regra prática
• Os requisitos devem ser numerados de forma
a poderem ser rastreados nas fases
subsequentes do desenvolvimento.


22

14-03-2012

Quais os requisitos essenciais para uma solução
de posto de venda para a empresa ABC?


Exemplo
Problema:


23

14-03-2012

Diagramas CU
• Representa uma acção entre um utilizador
(humano ou máquina) e um sistema;
• Descrevem a funcionalidade que um actor
necessita de executar para obter um
determinado resultado, um objectivo;
• Diagramas de alto nível, pouco detalhados;
• Sequência de acções que um ou mais actores
realizam num sistema [OMG99].


Diagramas CU
• O Diagrama de CU funciona frequentemente
como instrumento de comunicação com os
utilizadores.

Actores
ACTOR

Caso de Utilização
Casos de Utilização

24

14-03-2012

Diagramas UC
• Actor – Papel que um utilizador desempenha
relativamente ao sistema em análise. Também
pode corresponder a um SI ou hardware.
• Caso de Utilização – Especificação de uma
sequência de acções que um sistema pode
realizar interagindo com actores do sistema.


Regras Práticas
• Os UC são modelados como elipses;
• Os UC devem começar com um verbo no
infinitivo. Esta técnica dá enfoque à natureza
funcional dos UC. Por exemplo:
– “Levantar dinheiro”;
– “Agendar consulta”;
– “Efectuar inscrição”.
• Actores, figuras estilizadas de pessoas.


25

14-03-2012

Exemplo

Aplicação GesEscola

Efectuar Inscrição

Aluno


Cenário Principal e Secundário
A descrição do cenário pode assumir a forma
de texto livre ou estruturada, segundo um
conjunto de passos numerados.
As especificações do cenários devem incluir:
– Pressupostos;
– Pré-condições;
– Inicialização;
– (…).


26

14-03-2012

Cenário
Forma livre
Caso de utilização inicia-se quando o aluno
acede ao sistema GesEscola, selecciona uma
escola, verifica os cursos existentes e efectua a
sua inscrição no curso. Termina após inscrição.


Cenário
Forma estruturada
Efectuar Inscrição
Pré condição Aluno é utilizador válido.
1 – UC começa quando aluno selecciona a opção efectuar
inscrição;
2 – Sistema mostra lista de escolas;
3 – Aluno selecciona escola;
4 – Sistema mostra lista de cursos;
5 – Aluno selecciona curso;
6 – Aluno efectua inscrição.

Pós condição Aluno recebe comprovativo da inscrição.


27

14-03-2012

Proposta
Com base nos requisitos identificados na
empresa ABC vamos construir um modelo de
casos de utilização de alto nível.
1. Enumerar os actores que interagem com o
sistema;
2. Levantar casos de utilização (UC) do sistema.

Proposta


28

14-03-2012

Regras Práticas
Duas técnicas para levantamento de UCs
• Baseadas no actores:
– Identificar os actores relevantes relacionados com o
sistema ou organização;
– Para cada actor, identificar os processos que ele inicia
ou participa.
• Baseada em eventos:
– Identificar eventos do exterior que a empresa tem de
responder;
– Relacionar os eventos com actores e UCs.


Regras Práticas
• Depois de identificados, os UC são especificados
através de descrições textuais estruturadas. O nível de
detalhe é variável, podendo a descrição centrar-se na
intenção do UC (chamado de essencial – foco na
essência do processo) ou detalhar a sua
implementação concreta (chamado de real).
• Um UC essencial não está dependente de tecnologia
de implementação enquanto que um UC real refere as
opções concretas da sua realização ("Introduzir código
do produto" vs. "Ler código através de um leitor óptico
de códigos de barras").


29

14-03-2012

Regras Práticas
No processador de texto, escrever cada UC no
modo essencial.


Regras Práticas
De forma a evidenciar o actor, a descrição
geral do UC pode iniciar-se com uma estrutura
padrão do tipo:
• <Actor>;
• <Verbo>;
• <Acção>.


30

14-03-2012

Regras Práticas


Descrição detalhada do UC


31

14-03-2012

Descrição detalhada do UC


Proposta
Durante o semestre o Prof. Faísca foi enviando
os sumários com breves resumos da matéria
leccionada, via e-mail, para o sistema Fly2.
Após o fim das aulas, o Prof. Faísca utilizou a
interface web do sistema para actualizar cada
um dos sumários com descrições mais
completas das matérias leccionadas. Finda
essa actualização imprimiu os sumários e
enviou-os à Secretaria.

32

14-03-2012

Proposta
Neste caso identificamos os seguintes UCs:
1. Enviar sumários via e-mail;
2. Actualizar sumários via web;
3. Imprimir sumários (via web?/via e-mail?);
4. Enviar sumários à secretaria — deverá este use case ser
considerado?
No cenário descrito o envio é feito em papel. Não se trata,
portanto, de um serviço fornecido pelo sistema. No entanto,
podemos discutir a possibilidade de o envio passar a ser feito
electronicamente.
Durante o semestre o Prof. Faísca (1.) foi enviando os sumários com
breves resumos da matéria leccionada, via e-mail, para o sistema
Fly2. Após o fim das aulas, o Prof. Faísca (2.) utilizou a interface web
do sistema para actualizar cada um dos sumários com descrições
mais completas das matérias leccionadas. Finda essa actualização
(3.) imprimiu os sumários e (4.) enviou-os à Secretaria.

Proposta
Neste caso identificamos os seguintes Actores:
1. Docente;
2. Aluno;
3. Secretaria.

“Quem vai usar o sistema”


33

14-03-2012

Proposta
Diagrama de UC


Relações entre UC
As relações mais frequentes entre UC são
<<include>> e <<extend>> e generalização.
<<Include>> ou <<uses>> - Significa que um
determinado UC utiliza ou inclui a a
funcionalidade disponibilizada noutro UC;
<<extend>> - Ocorre quando existe um
comportamento opcional que deve ser incluído
num UC;
Generalização – Quando existe um caso particular
de outro UC.

34

14-03-2012

Include
Neste diagrama utiliza-se a relação <<include>>
para demonstrar que a funcionalidade “controlo
de acesso” é utilizada quando a encomenda é
feita pela internet. Alguns autores utilizam
<<uses>> em vez de <<include>>. Esta relação é
útil para evitar a duplicação de UC.


Extend
O mecanismo de pontos de extensão permite definir
no UC base onde o comportamento será incorporado,
sem alterar a sua descrição. Também garante que o
comportamento não se altera se ele deixe de existir
Neste diagrama utiliza-se a relação <<extend>> para
demonstrar que a funcionalidade “Desconto internet”
pode ser aplicada.


35

14-03-2012

Generalização
O comportamento do UC “efectuar
encomenda internet” é semelhante ao UC
“efectuar encomenda”, existindo apenas
variações especificas do meio onde é
efectuada a encomenda.


Generalização
A generalização possui as mesmas propriedades
que uma relação “pai/filho”, onde o UC filho
herda ou substitui por completo o
comportamento do UC pai, por exemplo o UC
“controlo de acesso” pode ser realizado de duas
formas diferentes, consoante seja efectuado na
loja ou na internet.


36

14-03-2012

Generalização
A relação também pode ser efectuada entre dois
actores. No exemplo é estabelecido uma relação
de generalização entre o actor “funcionário” e o
actor “empregado de balcão” (caso geral -> caso
específico). Esta relação evita a duplicação de
relações.


Generalização
O que significa esta generalização?.


37

14-03-2012

Generalização
Ilustre a seguinte generalização entre os
actores: Patrão e Empregado. Ambos são
recursos humanos de uma organização:
“Todas as manhãs os recursos da organização
registam a hora de entrada no relógio de
ponto da empresa ABC. Semanalmente, o
patrão extrai o registo de horas do relógio e
envia a listagem para o departamento de
recursos humanos.”


Revisão
Perguntas de revisão:
1. O que significa Use Case?
2. Qual a notação para Use Case?
3. O que significa Actor?
4. Qual a notação para Actor?
5. Para que servem os diagramas de UC?
6. Defina conceito de requisito.
7. Que tipos de requisitos existem?
8. Que tipos de relação podem ser efectuadas entre UC?
9. Qual a diferença entre <<extend>> e <<include>>?


38

14-03-2012

Revisão
1. O que significa Use Case?
Constituem a técnica UML para representar o
levantamento de requisitos de um sistema.
Desde sempre que o correcto levantamento de
requisitos no desenvolvimento de sistemas de
informação tenta garantir que o sistema seja útil
para o utilizador final, estando de acordo com as
necessidades
Elipse

Revisão
3. O que significa Actor?
Um actor representa uma entidade externa que
interage com o sistema.
Devem ser caracterizados através de um
pequena descrição, de forma a assegurar uma
correcta compreensão do significado do actor
por todos os elementos da equipa envolvida da
análise.
Figuras estilizadas de pessoas


39

14-03-2012

Revisão
5. Para que servem os diagramas de UC?
Para apresentação de requisitos e para
assegurar que tanto o utilizador final como o
perito numa determinada área, ou o
especialista informático possuem um
entendimento comum dos requisitos. O
objectivo é mostrar o que um sistema deve
efectuar e não como o vai fazer.


Revisão
6. Defina conceito de requisito
Funcionalidade ou característica considerada
relevante na óptica do utilizador.
Normalmente, representa um
comportamento esperado do sistema, que na
prática consiste num serviço que deve ser
disponibilizado a um utilizador.


40

14-03-2012

Revisão
7. Que tipos de requisitos existem?
Funcionais – Descrevem o que o sistema faz, ou se
pretende que faça. Requisitos levantados inicialmente.
Descrição de processamentos a efectuar pelo sistema,
inputs e outputs;
Não funcionais – Relacionados com as características
qualitativas do sistema, descrevendo a qualidade com que
o sistema deverá fornecer requisitos funcionais (tempos
de resposta);
Usabilidade – Garantem uma boa relação entre o sistema
desenvolvido, utilizadores do sistema e também as tarefas
que desempenham apoiados pelo sistema.


Revisão
8. Que tipos de relação podem ser efectuadas entre UC?
<<extend>>; <<include>> e generalização
9. Qual a diferença entre <<extend>> e <<include>>?
<<include>> - Significa que um determinado UC utiliza
ou inclui a a funcionalidade disponibilizada noutro UC;
<<extend>> - Ocorre quando existe um
comportamento opcional que deve ser incluído num
UC;


41

14-03-2012

Exercícios
De uma entrevista com o responsável de biblioteca de
uma universidade resultou a seguinte descrição para um
novo SI:
“Uma das actividades principais da biblioteca é efectuar o
empréstimo de publicações aos alunos da universidade. O
empréstimo é registado pelos funcionários da biblioteca,
que também consultam diariamente os empréstimos
cujos prazos foram ultrapassados. Todo este processo é
realizado manualmente, sendo muito ineficiente. Espera-
se que o novo sistema resolva esta situação. Os alunos
necessitam de pesquisar livros existentes na biblioteca.
Caso um livro esteja requisitado, é mostrada a data
esperada de entrega.”


Exercícios
Considere os seguintes requisitos de um SI para gestão de um
parque de estacionamento.
a) O controlo é efectuado com base na matrícula do veículo;
b) Na entrada do parque existirá um funcionário que introduz as
matrículas do sistema, ficando de imediato registado a data e hora
de início de estacionamento. O sistema tem de verificar as a
matrícula existe;
c) Se a matrícula não for reconhecida pelo sistema, então o
funcionário registará um novo veículo no sistema;
d) Na saída, um funcionário introduz novamente a matrícula,
calculando o sistema o custo do estacionamento;
e) O gestor do parque de estacionamento precisa de consultar
diariamente uma listagem dos estacionamentos. Em algumas
situações, o gestor poderá desempenhar as funções de
atendimento, no entanto, apenas o gestor poderá obter listagens.


42

Software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Software

Semelhante a Software (20)

Mais de Marco Coelho

Mais de Marco Coelho (20)

Último

Último (20)

Software