A maior rede de estudos do Brasil

Grátis
81 pág.
Apostila-UML

Pré-visualização | Página 3 de 18

a atividade de análise, que 
modela as estruturas internas de um sistema, é completamente dependente do paradigma 
adotado no desenvolvimento, como a Análise Orientada a Objetos, que apresenta os 
principais conceitos da orientação a objetos e a linguagem de modelagem unificada (UML) 
e explora a modelagem de análise segundo o paradigma de objetos; e a Análise Essencial 
de sistemas que apresenta os principais conceitos da análise essencial e discute a 
modelagem de análise segundo o método da análise essencial, que adota o paradigma 
estruturado. 
Processo de desenvolvimento de software 
 
 Um Processo de desenvolvimento de software é um conjunto de atividades, 
parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado 
dentro da área de Engenharia de Software, sendo considerado um dos principais 
mecanismos para se obter software de qualidade e cumprir corretamente os contratos de 
desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a t do 
software. 
 Passos/Atividades do Processo: 
 Análise de requisitos de software: A extração dos requisitos de um desejado 
produto de software é a primeira tarefa na sua criação. Embora o cliente, 
provavelmente, acredite saber o que o software deva fazer, esta tarefa requer 
 
 
 
7 
 
habilidade e experiência em engenharia de software para reconhecer a 
incompletude, ambigüidade ou contradição nos requisitos. 
 Especificação: A especificação é a tarefa de descrever precisamente o software que 
será escrito, preferencialmente de uma forma matematicamente rigorosa. Na 
prática, somente especificações mais bem sucedidas foram escritas para aplicações 
bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas 
de software de missão crítica sejam freqüentemente bem especificados antes do 
desenvolvimento da aplicação. Especificações são mais importantes para interfaces 
externas que devem permanecer estáveis. 
 Arquitetura de Software: A arquitetura de um sistema de software remete a uma 
representação abstrata daquele sistema. Arquitetura é concernente à garantia de que 
o sistema de software irá ao encontro de requisitos do produto, como também 
assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura 
também direciona as interfaces entre os sistemas de software e outros produtos de 
software, como também com o hardware básico ou com o sistema operacional. 
 Implementação (ou codificação): A transformação de um projeto para um código 
dever ser a parte mais evidente do trabalho da engenharia de software, mas não 
necessariamente a sua maior porção. 
 Teste: Teste de partes do software, especialmente onde tenha sido codificado por 
dois ou mais engenheiros trabalhando juntos, é um papel da engenharia de 
software. 
 Documentação: Uma importante tarefa é a documentação do projeto interno do 
software para propósitos de futuras manutenções e aprimoramentos. As 
documentações mais importantes são das interfaces externas. 
 Suporte e Treinamento de Software: Uma grande porcentagem dos projetos de 
software falha pelo fato de o desenvolvedor não perceber que não importa quanto 
tempo a equipe de planejamento e desenvolvimento irá gastar na criação do 
software se ninguém da organização irá usá-lo. As pessoas ocasionalmente resistem 
à mudança e evitam aventurar-se em áreas pouco familiares. Então, como parte da 
fase de desenvolvimento, é muito importante o treinamento para os usuários de 
software mais entusiasmados, alternando o treinamento entre usuários neutros e 
usuários favoráveis ao software. Usuários irão ter muitas questões e problemas de 
software os quais conduzirão para a próxima fase. 
 
 
 
8 
 
 Manutenção: A manutenção e melhoria de software lidam com a descoberta de 
novos problemas e requerimentos. Ela pode tomar mais tempo que o gasto no 
desenvolvimento inicial do mesmo. Não somente pode ser necessário adicionar 
códigos que combinem com o projeto original, mas determinar como o software 
trabalhará em algum ponto depois da manutenção estar completa, pode requerer um 
significativo esforço por parte de um engenheiro de software. Cerca de ⅔ de todos 
os engenheiros de software trabalham com a manutenção. Uma pequena parte 
destes trabalha na correção de erros. A maioria das manutenções é para ampliar os 
sistemas para novas funcionalidades, as quais, de diversas formas, podem ser 
consideradas um novo trabalho. Analogamente, cerca de ⅔ de todos os engenheiros 
civis, arquitetos e construtores trabalham com manutenção de uma forma similar. 
Visões de um Sistema 
 
 O desenvolvimento de um sistema complexo não é uma tarefa fácil. O ideal seria 
que o sistema inteiro pudesse ser descrito em um único gráfico e que este representasse por 
completo as reais intenções do sistema sem ambiguidades, sendo facilmente interpretável. 
Infelizmente, isso é impossível. Um único gráfico é incapaz de capturar todas as 
informações necessárias para descrever um sistema. 
 Um sistema é composto por diversos aspectos: funcional (que é sua estrutura 
estática e suas interações dinâmicas), não funcional (requisitos de tempo, confiabilidade, 
desenvolvimento, etc.) e aspectos organizacionais (organização do trabalho, mapeamento 
dos módulos de código, etc.). Então o sistema é descrito em um certo número de visões, 
cada uma representando uma projeção da descrição completa e mostrando aspectos 
particulares do sistema. 
 Cada visão é descrita por um número de diagramas que contém informações que 
dão ênfase aos aspectos particulares do sistema. Existe em alguns casos uma sobreposição 
entre os diagramas o que significa que cada um pode fazer parte de mais do que uma visão. 
Os diagramas que compõem as visões contêm os modelos de elementos do sistema. As 
visões que compõem um sistema são: 
 
 
 
 
Visão de Componentes Visão Lógica 
Visão de Use-case 
 
 
 
9 
 
 
 
 
 Visão "Use-case" (caso de uso): Descreve a funcionalidade do sistema 
desempenhada pelos atores externos do sistema (utilizadores). A visão use-case é 
central, já que seu conteúdo é base do desenvolvimento das outras visões do 
sistema. Essa visão é montada sobre os diagramas de use-case (caso de uso) e 
eventualmente diagramas de atividade. 
 Visão Lógica: Descreve como a funcionalidade do sistema será implementada. É 
feita principalmente pelos analistas, programadores e utilizadores. Em contraste 
com a visão use-case, a visão lógica observa e estuda o sistema internamente. Ela 
descreve e especifica a estrutura estática do sistema (classes, objectos, e 
relacionamentos) e as colaborações dinâmicas quando os objetos enviarem 
mensagens uns para os outros para realizarem as funções do sistema. Propriedades 
como persistência e concorrência são definidas nesta fase, bem como as interfaces e 
as estruturas de classes. A estrutura estática é descrita pelos diagramas de classes e 
objetos. O modelo dinâmico é descrito pelos diagramas de estado, sequência, 
Comunicação e atividade. 
 Visão de Concorrência: Trata a divisão do sistema em processos e processadores. 
Este aspecto, que é uma propriedade não funcional do sistema, permite uma melhor 
utilização do ambiente onde o sistema se encontrará, se o mesmo possui execuções 
paralelas, e se existe dentro do sistema uma gestão de eventos assíncronos. Uma 
vez dividido o sistema em linhas de execução de processos concorrentes (threads), 
esta visão de concorrência deverá mostrar como se dá a comunicação e a 
concorrência destas threads. A visão de concorrência é suportada pelos diagramas 
dinâmicos, que são os diagramas de estado, sequência, Comunicação e atividade, e 
pelos diagramas de implementação, que são os diagramas de componentes e de 
instalação. 
 Visão de Componentes: É suportada pelos diagramas de componentes que 
descrevem a implementação dos módulos e suas dependências. É principalmente 
executada por programadores.