Análise e Projeto de Software

Transcrição

1 Análise e Projeto de Software Material preparado pelo Prof. Marcelo Maia 363 Análise e Projeto 364 1

2 Projeto e Modelos Elicitação de Requisitos CIM Análise de Requisitos PIM Projeto do Sistema PSM Implementação Código Artefatos de Projeto Razões das Decisões (Design Rationale) Modelos de Projeto Modelos Arquiteturais Modelos de Dados Modelos da Interface com Usuário Modelos de Componentes Modelos de Implantação Padrões Arquiteturais Padrões de Projeto 2

3 Influências no Projeto Requisitos funcionais Requisitos não-funcionais Architecture The overall structure of the software and the ways in which that structure provides conceptual integrity for a system. [SHA95a] Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks. Fonte: Pressman 3

4 Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the software architecture. Fonte: Sommerville Architectural design An early stage of the system design process. Represents the link between specification and design processes. Often carried out in parallel with some specification activities. It involves identifying major system components and their communications (structural properties) Fonte: Sommerville 4

5 Advantages of explicit architecture Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. System analysis Means that analysis of whether the system can meet its non-functional requirements is possible. Large-scale reuse The architecture may be reusable across a range of systems. Fonte: Sommerville Architecture and system characteristics Performance Localise critical operations and minimise communications. Use large rather than fine-grain components. Security Use a layered architecture with critical assets in the inner layers. Safety Localise safety-critical features in a small number of subsystems. Availability Include redundant components and mechanisms for fault tolerance. Maintainability Use fine-grain, replaceable components. Fonte: Sommerville 5

6 Architectural conflicts Trade-offs Using large-grain components improves performance but reduces maintainability. Introducing redundant data improves availability but makes security more difficult. Localising safety-related features usually means more communication so degraded performance. Fonte: Sommerville System structuring Concerned with decomposing the system into interacting sub-systems. The architectural design is normally expressed as a block diagram presenting an overview of the system structure. More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed. Fonte: Sommerville 6

7 Box and line diagrams Very abstract - they do not show the nature of component relationships nor the externally visible properties of the sub-systems. However, useful for communication with stakeholders and for project planning. Difficult for profound evaluation Fonte: Sommerville Packing robot control system Fonte: Sommerville 7

8 Diagrama de componentes Abstract, but they do show the nature of component relationships and the externally visible properties of the sub-systems. Yet, useful for communication with stakeholders and for project planning. Better for more profound evaluation Next step: refine Diagrama de Componentes Sistema Web 8

9 Architectural design decisions Architectural design is a creative process so the process differs depending on the type of system being developed. However, a number of common decisions span all design processes. Fonte: Sommerville Architectural design decisions Is there a generic application architecture that can be used? How will the system be distributed? What architectural styles are appropriate? What approach will be used to structure the system? How will the system be decomposed into modules? What control strategy should be used? How will the architectural design be evaluated? How should the architecture be documented? Fonte: Sommerville 9

10 Architecture reuse Systems in the same domain often have similar architectures that reflect domain concepts. Application product lines are built around a core architecture with variants that satisfy particular customer requirements. Fonte: Sommerville Architectural styles Architecture patterns The architectural model of a system may conform to a generic architectural model or style. An awareness of these styles can simplify the problem of defining system architectures. However, most large systems are heterogeneous and do not follow a single architectural style. Fonte: Sommerville 10

11 Architectural models Used to document an architectural design. Static structural model that shows the major system components. Dynamic process model that shows the process structure of the system. Interface model that defines sub-system interfaces. Relationships model such as a data-flow model that shows subsystem relationships. Distribution model that shows how sub-systems are distributed across computers. Fonte: Sommerville Reference architectures Reference models are derived from a study of the application domain rather than from existing systems. May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated. OSI model is a layered model for communication systems. Fonte: Sommerville 11

12 OSI reference model Fonte: Sommerville Key points The software architecture is the fundamental framework for structuring the system. Architectural design decisions include decisions on the application architecture, the distribution and the architectural styles to be used. Different architectural visions such as a structural model, a control model may be developed. System organisational models (patterns) include repository models, client-server models and abstract machine models. Fonte: Sommerville 12

13 Key points Modular decomposition models include object models and pipelining models. Control models include centralised control and event-driven models. Reference architectures may be used to communicate domain-specific architectures and to assess and compare architectural designs. Fonte: Sommerville Padrões de Arquitetura 13

14 Padrões Nome do padrão Problema: quando aplicar o padrão? Descreve o problema e seu contexto. Solução: elementos que definem o projeto, seus relacionamentos, responsabilidades e colaborações. É como um template que pode ser usado em várias situações. Conseqüências são resultados e trade-offs (compromissos) de se aplicar os padrões. Relacionadas aos trade-offs de espaço e tempo. Como o reúso é um fator importante as conseqüências incluem o impacto na flexibilidade, estensibilidade e portabilidade do sistema. Fonte: GoF Classificação de Padrões Padrões Os padrões de projeto podem ser classificados de acordo com a fase de desenvolvimento em que são mais adequados: Padrões de Análise (Analysis patterns) Seu foco é na fase de análise ou modelamento de negócio Padrões ligados ao domínio do problema Padrões de Arquitetura (Architectural patterns) Seu foco é na arquitetura do software Padrões de Projeto (Design patterns) Foco no projeto de componentes do software Muitas das vezes os padrões podem estar muito ligados tanto ao domínio da solução, quanto do problema

15 Classificação de Padrões Padrões Padrões de Análise (Analysis patterns) Martin Fowler, 1996 Padrões de Arquitetura (Architectural patterns) Apresentado inicialmente por Frank Buschmann et al., 1996 Computação Distribuída - Frank Buschmann et al., 2007 Padrões de Projeto (Design patterns) GOF (Gang of Four) E. Gamma, R. Helm, R. Johnson, J. Vlissides 1995 Aplicações Concorrentes e em Rede - Frank Buschmann et al Enterprise Integration Patterns Gregor Hohpe, 2003 Real-time Design Patterns Bruce Douglass, 2003.Net Design Patterns - Christian Thilmany, 2003 J2EE Design Patterns - Deepak Alur, 2003 Web Services Patterns Paul Monday, 2003 Ajax Design Patterns - Michael Mahemoff, 2006 SOA Design Patterns Thomas Erl, Padrões de Análise (Analysis Patterns) Proposto por Martin Fowler, em livro publicado em 1996 Notação do Livro não é baseada em UML Baseada em áreas (domínios) específicas como: manufatura; financeira e saúde Mesmo assim, padrões podem apresentados podem ser úteis em outros domínios Alguns princípios apresentados Um modelo não está certo ou errado, eles podem ser mais ou menos úteis Modelos conceituais estão ligados a tipos (interfaces) e não implementações (classes) Padrões são o ponto de partida, não o destino Sempre que possível, quando existir um tipo e um supertipo, considere colocar os recursos no supertipo, desde que isto faça sentido Quando múltipos atributos possuam um comportamento relacionado e presente em muitos tipos, combine estes atributos em um novo tipo fundamental

16 Padrões de Análise (Analysis Patterns) Exemplos de alguns padrões de projeto Quantity (3.1) Conversion Ratio (3.2) Compound Units (3.3) Measurement (3.4) Observation (3.5) Range (4.3) Name (5.1) Account (6.1) Transaction (6.2) Summary Account (6.3) Plan (8.4) Contract (9.1) Product (10.3) Associative Type (15.1) 393 Padrões de Arquitetura (Architectural patterns) Expressam uma organização fundamental de estrutura de um software O ponto de partida da análise orientada a objetos é a criação do chamado Domain Model O Domain Model expressa as classes ligadas ao domínio do problema Os padrões de arquitetura auxiliam na concepção do software e na transição para o domínio da solução Alguns padrões de arquitetura Layers Model-View-Controler (MVC) Pipes and Filters Microkernel Shared Repository

17 Padrões de Projeto (Design Patterns) Trabalho proposto inicialmente por Erich Gamma, Richard Helm, Ralph Jonhson, John Vlissides (Gang of Four) em 1995 Famílias de Padrões De Criação Responsáveis pela criação de objetos Permitem que o sistema fique independente da forma como os objetos são criados Factory, Abstract Factory, Singleton, Builder, Prototype Estruturais Relacionados com a forma com que classes e objetos são compostos a fim de formar estruturas maiores Adapter, Bridge, Composite, Decorator, Facade, Proxy Comportamentais Relacionados com a atribuição de responsabilidades entre objetos Descrevem a comunicação entre objetos Chain of Responsibility, Command, Flyweigth, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, Visitor 395 Layer Permite o desenvolvimento de forma independente de diferentes partes do sistema de software

18 Layer Usos com outros padrões 397 Estilos (padrões) de Arquitetura Camadas Fonte: Buschmann 18

19 Camadas (Windows NT) Pipes and Filters Arquitetura especializada em tratar fluxos de dados (data streams)

20 Pipes and Filters Uso com outros padrões 401 Estilos (padrões) de Arquitetura Dutos e Filtros Fonte: Buschmann 20

21 Estilos (padrões) de Arquitetura Dutos e Filtros Fonte: Buschmann Dutos e Filtros Atividade começando com o data source Fonte: Buschmann 21

22 Dutos e Filtros Atividade começando com o data sink Fonte: Buschmann Dutos e Filtros Mix pull-push (Source/Sink passivos) Fonte: Buschmann 22

23 Dutos e Filtros Filtros ativos Fonte: Buschmann Broker - estrutura Fonte: Buschmann 23

24 Broker dinâmica requisição de serviço pelo cliente Fonte: Buschmann Broker dinâmica uso de pontes Fonte: Buschmann 24

25 Model-View-Controller Uso Em situações onde a interface do usuário de uma aplicação pode mudar de forma mais frequente que o seu domínio 411 Model-View-Controller Uso do MVC com outros padrões

26 MVC - Estrutura Fonte: Buschmann MVC Dinâmica Inicialização Fonte: Buschmann 26

27 MVC Dinâmica Tratamento de eventos Fonte: Buschmann Microkernel Uso Arquitetura com suporte para escalabilidade funcional e adaptável para diferentes cenários de implantação

28 Microkernel Uso com outros padrões 417 Microkernel 28

29 Microkernel Cliente chamando serviço Microkernel Servidor externo requisitando serviço 29

30 Monolítico x Microkernel JBoss - JMX 30

31 JBoss JMX Camadas - Microkernel Shared Repository Uso Aplicações em que partes operam e são coordenadas através de um conjunto de dados compartilhados Caso de aplicações orientadas a dados e onde a interação entre os componentes não seguem regras específicas que possibilitem sua conexão A conexão entre os componentes e aplicações é feita através dos dados

32 Shared Repository Uso com outros padrões 425 Integração de Aplicações Orientada a processos Enterprise Application Integration Enterprise Service Bus Orientada a Dados ETL (Expose, Transform, Load) EII (Enterprise Information Integration) 32

33 Integração de Aplicações Comparação das abordagens 33

34 Enterprise Application Integration (EAI) EAI refers to message-based, transaction-oriented, application-to-application integration using either an integration pattern point- to-point or; a point-to-hub (brokering or bus) Padrões para integração orientada a processos Hub (broker) x Ponto a ponto 34

35 Evolução de integração de aplicações 1960 Hardware incompatível implicava em reescrever tudo (ex: 1991) Aplicações em batch (lotes) escrita em silos e compartilhamento através de arquivos Evolução de integração de aplicações Cliente-servidor Escolhas da infra-estrutura de rede. No início não havia arquitetura de rede amplamente aceita. Funções de comunicação tinham que ser adicionadas na aplicação requerendo maior habilidade dos programadores As APIs eram bastante complexas, sendo necessário muito tratamento de exceção e lógica de recuperação para se ter sucesso. 35

36 Evolução de arquiteturas clienteservidor RPC requer o servidor sempre disponível... Middleware de Filas de Mensagens 36

37 Adaptadores de formato Message brokers 37

38 Integração via Business Process Management Um requisição de serviço de um cliente pode chegar por inúmeros canais, tais como, telefone, mensagem de voz, fax, e até mesmo via carta convencional. Tal evento precisa ser capturado, categorizado e enviado pela organização através de um caminho predefinido, sendo monitorado por um sistema de gerenciamento que garante que a solução (e satisfação do cliente) serão atingidas dentro de certo prazo, e que qualquer intercorrência seja detectada, escalonada e remediada de acordo com parâmetros específicos de níveis de serviço. Impacto da Internet Tecnologia para Web Services Extensible Markup Language (XML) SOAP (originally an acronym for Simple Object Access Protocol) is na application-to-application protocol that isolates network, transport, programming language, and platform differences to allow a client to call a remote service without knowledge of how the service is coded or where the service is hosted. The message format is XML. Web Services Description Language (WSDL) is an XML-based interface and interface description language. The service provider uses a WSDL document in order to specify the operations a Web service provides, the parameters and data types of these operations and the location and transport bindings to be used to access the service. Web Services Inspection Language (WSIL) is an XML-based specification about how to locate Web services without the necessity of using UDDI. However, WSIL can be also used together with UDDI, that is, it is orthogonal to UDDI and does not replace it. Universal Description, Discovery, and Integration (UDDI) is both a client-side API and a SOAP-based server implementation that can be used to store and retrieve information on service providers and Web services. 38

39 Evolução de EAI Service-oriented Architecture SOA is an integration architecture approach based on the concept of a service. The business and infrastructure functions are provided as services that collectively, or individually, deliver application functionality to either end-user applications or other services. Applications collaborate by invoking each other s services. Services are composed into larger sequences to implement business processes. SOA requires a consistent mechanism for services to communicate: loosely coupled use of explicit interfaces. 39

40 O que é serviço? A service is a discrete function that is offered to an external consumer. Consumer: Web page, another business function, or a collection of functions that together form a process. Additional aspects: Services encapsulate reusable business function. Services are defined by explicit, implementationindependent interfaces. Services are defined in a way that stress location and transport transparency. SOA x Web Services Web Services A means to create welldocumented interfaces for services using standards such as Web services Definition Language (WSDL) and document-style SOAP A means to compose Web services using Business Process Execution Language for Web Services (WS-BPEL) Simple communication mechanisms that are location-transparent and interoperable SOA Architectural patterns for realizing a business design through the implementation and composition of software services A reference architecture model to decompose the functional components of an integration solution A model for the life cycle and governance of services to help make reusability of services a reality 40

41 Evolução de EAI SOA Service Oriented Architecture Registro Procura Contrato Publica Consumidor Interage Provedor

42 Abstrações de SOA Elementos do serviço 42

43 Elementos de SOA Tipos de serviços 43

44 Arquitetura tradicional x SOA Exemplo companhia aérea 44

45 Evolução de EAI Providing a consumer view of a service decoupled from the deployed implementation of the underlying application or service Decoupling technical aspects of service interactions Unifying access to applications using a common service model Providing dynamic access to services described in a service repository SOA sem ESB 45

46 SOA com ESB Funções de Middleware do ESB Map service requests from one protocol and address to another. Transform data formats. Support a variety of security and transactional models between service consumers and service providers and recognize that consumers and providers may support or require different models. Aggregate or disaggregate service requests and responses. Support communication protocols between multiple platforms with appropriate qualities of service. Provide messaging capabilities such as message correlation and publish/subscribe to support different messaging models such as events and asynchronous request/response. E idealmente: Support high volumes of individual interactions. Support more established integration styles, such as message-oriented and eventdriven integration, to extend the reach of the SOA. 46

47 Visão de alto nível do ESB Arquitetura de referência SOA 47

48 Service component architecture 48

49 Análise e Projeto Orientado a Objetos Utilizando UML Orientação a Objetos Alguns Conceitos OBJETO MÉTODO MENSAGEM CLASSE CLASSIFICAÇÃO GENERALIZAÇÃO ESPECIALIZAÇÃO HERANÇA POLIMORFISMO SOBRECARGA ENCAPSULAMENTO ABSTRAÇÃO MODULARIZAÇÃO

50 Análise Orientada a Objetos (OOA) Projeto Orientado a Objetos (OOD) A utilização do orientação à Objetos solicita uma nova forma de abstrair e entender o problema. A linguagem UML é um padrão de diagramação para visualizar os resultados da análise e projeto orientados à objetos 461 Análise Orientada a Objetos (OOA) Projeto Orientado a Objetos (OOD) Exemplo O conceito Livro em um sistema de biblioteca

51 Análise Orientada a Objetos(OOA) Objetivo básico Identificar classes a partir das quais objetos serão representados como instâncias Envolve as seguintes tarefas Identificação de Objetos Especificação de Atributos Definição de métodos Comunicações entre objetos 463 Análise Orientada a Objetos(OOA) IDENTIFICAÇÃO DE OBJETOS Entidades externas (Outros sistemas; dispositivos;pessoas) Coisas ligadas ao domínio do problema (Relatórios;Displays; ) Ocorrências ou Eventos (Conclusão de um movimento;alarme disparado; Clique do mouse; etc.) Papéis ou funções (Engenheiro; Gerente; Vendedor) desempenhados por pessoas Unidades organizacionais (Grupo; Equipe; ) Lugares (Piso de fábrica; área de descarga) Estruturas (Sensores; veículos de quatro rodas; )

52 Análise Orientada a Objetos(OOA) IDENTIFICAÇÃO DE OBJETOS CRITÉRIOS 1. RETENÇÃO DE INFORMAÇÃO Objeto deve guardar informação que será utilizada pelo sistema 2. SERVIÇOS NECESSÁRIOS Conjunto de operações identificáveis que podem mudar o valor de seus atributos 3. MÚLTIPLOS ATRIBUTOS Objeto deve conter mais de um atributo 4. ATRIBUTOS COMUNS Conjunto de atributos deve ser aplicado a todos os objetos 5. OPERAÇÕES COMUNS Conjunto de operações devem ser aplicáveis a todos os objetos. 6. REQUISITOS ESSENCIAIS Entidades externas que aparecem no espaço problema que consomem e/ou produzem informação 465 Análise Orientada a Objetos(OOA) Em uma especificação: NOMES são potenciais objetos (e classes) VERBOS são potenciais métodos A regra acima deve ser utilizada apenas como referência. O entendimento do contexto, das necessidades do usuário são fundamentais para classificar possíveis objetos e métodos

53 Análise Orientada a Objetos(OOA) Exemplo Especificação O software SafeHome possibilita que o dono da casa configure o sistema de segurança quando ele for instalado, monitora todos os sensores ligados ao sistema de segurança e interage com o dono da casa através de um teclado (key pad) e teclas de função contidas no painel de controle do SafeHome. Durante a instalação o painel de controle é usado para programar e configurar o sistema. A cada sensor é atribuído um número e um tipo, uma senha mestra é programada para armar e desarmar o sistema e números telefônicos são introduzidos para serem discados quando ocorrer um evento sensor. Quando um evento sensor é sentido pelo software, ele dispara um alarme sonoro ligado ao sistema. Após um tempo de espera, que é especificado pelo dono da casa durante as atividades de configuração do sistema, o software disca um número telefônico do serviço de monitoração, oferece informações sobre o local, registrando a natureza do evento que foi detectado. O número será novamente discado a 20 segundos até que a ligação telefônica seja completada. Todas as interações com o SafeHome são gerenciadas por um subsistema de interação com o usuário, que lê a entrada fornecida através do teclado e das chaves de função, exibe mensagens de prompting e informações sobre o status do sistema no mostrador de cristal líquido (LCD). A interação com o teclado assume a seguinte forma Análise Orientada a Objetos(OOA) Exemplo Especificação O software SafeHome possibilita que o dono da casa configure o sistema de segurança quando ele for instalado, monitora todos os sensores ligados ao sistema de segurança e interage com o dono da casa através de um teclado (key pad) e teclas de função contidas no painel de controle do SafeHome. Durante a instalação o painel de controle é usado para programar e configurar o sistema. A cada sensor é atribuído um número e um tipo, uma senha mestra é programada para armar e desarmar o sistema e números telefônicos são introduzidos para serem discados quando ocorrer um evento sensor. Quando um evento sensor é sentido pelo software, ele dispara um alarme sonoro ligado ao sistema. Após um tempo de espera, que é especificado pelo dono da casa durante as atividades de configuração do sistema, o software disca um número telefônico do serviço de monitoração, oferece informações sobre o local, registrando a natureza do evento que foi detectado. O número será novamente discado a 20 segundos até que a ligação telefônica seja completada. Todas as interações com o SafeHome são gerenciadas por um subsistema de interação com o usuário, que lê a entrada fornecida através do teclado e das chaves de função, exibe mensagens de prompting e informações sobre o status do sistema no mostrador de cristal líquido (LCD). A interação com o teclado assume a seguinte forma

54 Análise Orientada a Objetos(OOA) NOME dono da casa sistema de segurança sensores teclado teclas de função painel de controle número Tipo senha mestra números telefônicos evento sensor alarme sonoro tempo de espera Serviço de monitoração informações sobre o local natureza do evento subsistema entrada chaves de função mensagens mostrador de cristal líquido CRITÉRIO Papel ou entidade externa Coisa Entidade externa Entidade externa Entidade externa Entidade externa Atributo do sensor Atributo do sensor Coisa Coisa Ocorrência Entidade externa Atributo do sistema Unidade Organizacional ou Ent. Externa Atributo do sistema Atributo do sistema Entidade externa Entidade externa Entidade externa Entidade externa Entidade externa 469 Análise Orientada a Objetos(OOA) NOME CRITÉRIO dono da casa Rejeitado: 1 e 2 falham embora 6 se aplique sistema de segurança Aceito: Todas se aplicam sensores Aceito: Todas se aplicam teclado Aceito: Todas se aplicam teclas de função Aceito: Todas se aplicam painel de controle Aceito: Todas se aplicam número Rejeitado: 3 falha Tipo Rejeitado: 3 falha senha mestra Rejeitado: 3 falha números telefônicos Rejeitado: 3 falha evento sensor Aceito: Todas se aplicam alarme sonoro Aceito: 2, 3, 4, 5 e 6 tempo de espera Rejeitado: 3 falha Serviço de monitoração Rejeitado: 1 e 2 falham embora 6 se aplique informações sobre o local Rejeitado: 3 falha natureza do evento Rejeitado: 3 falha subsistema Aceito: Todas se aplicam entrada Rejeitado: 3 falha chaves de função Aceito: Todas se aplicam mensagens Aceito: Todas se aplicam mostrador de cristal líquido Aceito: Todas se aplicam

55 Identificação de Objetos Os objetos do painel de controle serão considerados separadamente. Os objetos abaixo são o ponto de partida para o desenvolvimento do sistema Objetos ainda não possuem atributos e métodos class Classes Sistema - atributos + metodos() : void PainelControle - atributos + metodos() : void Sensor - atributos + metodos() : void EventoSensor - atributos + metodos() : void AlarmeSonoro - atributos + metodos() : void 471 Especificação de Atributos Necessário estudar e analisar a descrição do sistema Pergunta Importante Quais informações definem este objeto? class Classes Sistema - senhamestra - tempoespera - numerostelefonicos - informacoeslocal - naturezaevento PainelControle - atributos + metodos() : void Sensor - tipo - numero + metodos() : void + metodos() : void EventoSensor - atributos + metodos() : void AlarmeSonoro - atributos + metodos() : void

56 Definição dos Métodos Necessário estudar e analisar a descrição do sistema Verbos são potenciais operações Configure Instalado Monitora Ligados Interage Instalação programar configurar programada armar desarmar introduzidos serem discados ocorrer sentido dispara especificado configuração disca registrando detectado Discado ligação interações gerenciadas interação lê fornecida exibe class Classes Sistema - senhamestra - tempoespera - numerostelefonicos - informacoeslocal - naturezaevento + programar() : void + armar() : void + desarmar() : void + monitorar() : void + dispararalarme() : void + discar() : void 473 Análise Orientada a Objetos(OOA) O departamento de obras públicas da cidade de Uberlândia decidiu desenvolver um sistema de computador para rastreamento e conserto de buracos de rua (SIRCOB). À medida que são registrados buracos de rua, eles recebem um número de identificação e são armazenados de acordo com o endereço da rua, tamanho (numa escala de 0 a 10), localização (no meio dar rua; na calçada; etc.), bairro (determinado a partir do endereço da rua) e prioridade de reparo (determinada a partir do tamanho do buraco). Dados de ordem de trabalho são associados a cada buraco, e eles incluem localização e tamanho do buraco, número de identificação da equipe de reparos, número de pessoas na equipe, equipamentos designados, horas aplicadas ao reparo, status do trabalho (em andamento, concluído, não concluído), quantidade de material de enchimento usado e custo do reparo (computado a partir das horas trabalhadas, número pessoas, material e equipamentos usados). Finalmente, um arquivo de danos ocorridos é criado para guardar informações sobre danos registrados devido ao buraco, o qual inclui o nome do cidadão, endereço, número telefônico, tipo de dano e a quantia em reais a ser paga. O SIRCOB é um sistema on-line; as consultas devem ser feitas interativamente

57 Análise Orientada a Objetos(OOA) O departamento de obras públicas da cidade de Uberlândia decidiu desenvolver um sistema de computador para rastreamento e conserto de buracos de rua (SIRCOB). À medida que são registrados buracos de rua, eles recebem um número de identificação e são armazenados de acordo com o endereço da rua, tamanho (numa escala de 0 a 10), localização (no meio dar rua; na calçada; etc.), bairro (determinado a partir do endereço da rua) e prioridade de reparo (determinada a partir do tamanho do buraco). Dados de ordem de trabalho são associados a cada buraco, e eles incluem localização e tamanho do buraco, número de identificação da equipe de reparos, número de pessoas na equipe, equipamentos designados, horas aplicadas ao reparo, status do trabalho (em andamento, concluído, não concluído), quantidade de material de enchimento usado e custo do reparo (computado a partir das horas trabalhadas, número pessoas, material e equipamentos usados). Finalmente, um arquivo de danos ocorridos é criado para guardar informações sobre danos registrados devido ao buraco, o qual inclui o nome do cidadão, endereço, número telefônico, tipo de dano e a quantia em reais a ser paga. O SIRCOB é um sistema online; as consultas devem ser feitas interativamente. 475 Identificação dos Objetos NOMES CLASSIFICAÇÃO ANÁLISE departamento Unidade Organizacional Rejeitado: 1 e 2 Falham sistema coisa Aceito: Todas se aplicam buracos coisa Aceito: Todas se aplicam número de identificação coisa Rejeitado: 3 falha endereço da rua coisa Rejeitado: 3 falha tamanho coisa Rejeitado: 3 falha localização coisa Rejeitado: 3 falha bairro bairro Rejeitado: 3 falha prioridade coisa Rejeitado: 3 falha ordem de trabalho coisa Aceito: Todas se Aplicam número de identificação da equipe coisa Rejeitado: 3 falha número de pessoas coisa Rejeitado: 3 falha equipamentos coisa Rejeitado: 3 falha horas coisa Rejeitado: 3 falha quantidade coisa Rejeitado: 3 falha custo coisa Rejeitado: 3 falha arquivo de danos estrutura Aceito: Todas se aplicam nome do cidadão coisa Rejeitado: 3 falha Endereço coisa Rejeitado: 3 falha número telefônico coisa Rejeitado: 3 falha tipo de dano coisa Rejeitado: 3 falha