Desenvolvimento De Software

1. INTRODUÇÃO

O analista de sistemas deve garantir o alinhamento entre tecnologia e estratégias organizacionais, os projetos de software devem conhecer o cenário organizacional em um nível suficiente, a ponto de avaliar e sugerir melhorias, ou ate mesmo reengenharia nos processos de negócios.

Este trabalho mostrara na pratica a importância das técnicas e conceitos da UML, através do diagrama de atividades, bem como a modelagem de dados na utilização dos bancos de dados relacionais juntamente com a programação orientada a objetos, viabilizando o sucesso dos sistemas no que tange o alinhamento dos objetos aos processos das organizações.

2. DESENVOLVIMENTO

2.1 UML – DIAGRAMA DE ATIVIDADES

O diagrama de atividades, geralmente é apresentado como parte da descrição funcional de um sistema, devido ao fato de especificar processos lógicos(atividades do sistema e dos fluxos de dados ou decisões). Nele são apresentadas as relações entre cada atividade de um determinado processo, em que podem ser vistas as relações de dependência entre essas atividades, e quem são os responsáveis pelas suas execuções.

2.1.1 CENÁRIO ATUAL

Respeitando ao máximo o texto da proposta e abstraindo algumas situações do cenário atual da empresa sobre sua rotina de trabalho, estipulamos que o cliente chega à loja e vai até as prateleiras, escolhe o exemplar que deseja eleva até o atendente para efetivar a locação. Ou então, se a intenção é devolver o(s) livro(s) na sua totalidade, solicita ao funcionário a baixa do empréstimo.

2.2 MODELO CONCEITUAL COM MRN APLICADO

O modelo relacional foi inventado pelo Dr. Codd e subseqüentemente mantido e aprimorado por Chris Date e Hugh Darwen como um modelo geral de dados.A normalização de dados é uma série de passos que se segue no projeto de um banco de dados que permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados relacional. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem inconsistentes.Procuramos obedecer e respeitar todas as regras de negócios impostas na proposta, entretanto, depois de uma minuciosa análise em grupo,assumimos algumas adaptações visando melhorar a utilização do software pelo usuário e nos preocupando em não “engessá-lo” na modelagem.Por exemplo, quanto ao cadastro de autores, a regra de negócio diz que um livro deve ter 1 ou vários autores. Significa dizer, que ao se cadastrar um autor, obrigatoriamente, devemos relacioná-lo a um livro pelo menos.Imaginemos que um funcionário comprou 200 livros de uma grande livraria e deseja cadastrá-los antes mesmo de recebê-los. Para isso, solicitou a outro funcionário que fosse lançando os nomes dos autores para depois agilizar o trabalho de cadastro dos livros. Pela regra original isso não seria possível!Portanto, na nossa concepção de modelagem, deixamos em aberto esta possibilidade colocando a cardinalidade de (0,n) na entidade AUTOR, ou seja,pode-se cadastrar N autores e depois na tela de cadastro de livros ligamos livro a autor(es). Essa adaptação não fere a regra de negócios, pois ainda sim, um livro não pode ser incluído sem um