quarta-feira, 23 de abril de 2008
segunda-feira, 21 de abril de 2008
sábado, 19 de abril de 2008
Falácia
De Wiki.Ateus.Network
Conteúdo
[esconder]Definição
Falácia é um argumento ardiloso que induz ao erro. Muito usada em discussões filosóficas, proporciona a quem dela faz uso a possibilidade de defender um ponto de vista sem que faça uso de um raciocínio lógico e correto.
Por ser um método que muitas vezes traz resultados — duvidosos —, há um sem-número de tipos de falácia. Todavia, tais resultados existem não apenas pelo caráter dialético do argumento falacioso, mas sobretudo em virtude de um mau preparo intelectual: um raciocínio enganoso pode ser facilmente reconhecido caso houver o conhecimento básico dos muitos ardis empregados na a defesa de idéias.
QUOTE
O objetivo de um argumento é expor as razões que sustentam uma conclusão. Um argumento é falacioso quando parece que as razões apresentadas sustentam a conclusão, mas na realidade não sustentam. Da mesma maneira que há padrões típicos, largamente usados, de argumentação correta, também há padrões típicos de argumento falacioso. (Stephen Downes)
Para o aristotelismo, trata-se de qualquer raciocínio ou parte de um discurso que simula uma veracidade. Esta aparente autenticidade é denominada sofisma. Já para a escolástica, falácia é o termo utilizado para caracterizar o silogismo sofístico do aristotelismo — que consiste em um raciocínio plausível, porém inverídico.
Tipos de falácias
- Falácias da Dispersão (manobras de diversão)
- Falso dilema (falsa dicotomia)
- Apelo à ignorância
- Derrapagem (bola de neve ou declive ardiloso)
- Pergunta complexa
- Apelo a Motivos (em vez de razões)
- Apelo à força
- Apelo à piedade
- Apelo a conseqüências
- Apelo a preconceitos
- Apelo ao povo
- Fugir ao Assunto (falhar o alvo)
- Ataques pessoais
- Apelo à autoridade
- Autoridade anônima
- Estilo sem substância
- Falácias indutivas
- Generalização precipitada
- Amostra não representativa
- Falsa analogia
- Indução preguiçosa
- Omissão de dados
- Falácias com regras gerais
- Falácia do acidente
- Falácia inversa do acidente
- Falácias causais
- Post hoc
- Efeito conjunto
- Insignificância
- Tomar o efeito pela causa
- Causa complexa
- Falhar o alvo
- Petição de princípio
- Conclusão irrelevante
- Espantalho
- Falácias da ambigüidade
- Equívoco
- Anfibologia
- Ênfase
- Erros categoriais
- Falácia da composição
- Falácia da divisão
- Non sequitur
- Falácia da afirmação da conseqüente
- Falácia da negação da antecedente
- Falácia da inconsistência
- Falácias da explicação
- Inventar fatos
- Distorcer fatos
- Irrefutabilidade
- Âmbito limitado
- Pouca profundidade
- Erros de definição
- Definição demasiado lata
- Definição demasiado restrita
- Definição pouco clara
- Definição circular
- Definição contraditória
(para mais detalhes, q.v. Guia de Falácias em Ligações Externas)
A falácia divina
A falácia é um raciocínio condizente com a natureza da fé, isto é, torna-se uma grande aliada no que concerne à defesa de argumentos que sustentem a hipótese da existência de um deus. Para tal, dentre muitas possíveis, a falácia divina é um argumento no estilo Não posso perceber isto, portanto foi Deus quem fez ou Isto é muito estranho, portanto Deus está por trás.
Com incontáveis variações, esta falácia é uma das muitas ferramentas — ditas lógicas — utilizadas por quem defende algum tipo de trâmite metafísico.
Ligações externas
Retirado de "http://ateus.net/wiki/index.php?title=Fal%C3%A1cia"
Argumento
De Wiki.Ateus.Network
Conteúdo
[esconder]- 1 Introdução
- 2 Definição
- 3 O argumento na Lógica aristotélica
- 4 O argumento nas ciências jurídicas
- 5 Bibliografia
- 6 Ligações externas
Introdução
Em linhas gerais, argumento é sinônimo de prova, razão, demonstração. Trata-se de um meio utilizado para convencer alguém acerca de algo. É visto, ainda, como parte principal de um discurso, ou seja, aquilo que sustenta um tema.
Definição
Argumento é um conjunto de afirmações que, de tal maneira encadeadas, permitem o encontro de uma conclusão.
Para diferenciar um argumento de um raciocínio, deve-se atentar para o fato de que o argumento é uma ferramenta lógica de persuasão, enquanto um raciocínio fomenta-se em saber se determinada conclusão é ou não o resultado de determinado conjunto de afirmações.
Mesmo que as afirmações usadas nos argumentos sejam verdadeiras ou falsas, os argumentos não podem ser verdadeiros nem falsos — pois não são afirmações, e sim conjuntos de afirmações.
A partir de certa estruturação, torna-se improvável (ou mesmo impossível) que uma conclusão seja falsa se esta resultar de premissas verdadeiras. Nesse caso, pode-se dizer que o argumento é válido.
Em Lógica, todo raciocínio objetiva partir daquilo que já se conhece para que seja possível chegar àquilo que se ignora. Dessa forma, existem duas possibilidades para que isso ocorra, a saber, ou partimos de uma lei universal (dedução) ou partimos de vários casos singulares (indução).
A dedução e a indução são operações do pensamento que consistem em tirar de duas ou mais proposições uma outra proposição que decorrem logicamente das anteriores.
A Dedução
O argumento dedutivo é uma forma de raciocínio que parte, geralmente, de uma verdade universal para se chegar a uma verdade paticular ou singular.
Este método de raciocínio é válido quando suas premissas, enquanto verdadeiras, podem fornecer provas evidentes para uma conclusão. Esta, por se originar necessariamente de premissas válidas, tem como característica a necessidade de ser também ser válida. É mister notar que em todo argumento dedutivo a conclusão já está presente nas premissas.
"Um raciocínio dedutivo é válido quando suas premissas, se verdadeiras, fornecem provas convincentes para sua conclusão, isto é, quando as premissas e a conclusão estão de tal modo relacionados que é absolutamente impossível as premissas serem verdadeiras se a conclusão tampouco for verdadeira." (COPI, 1978, p.35)
Em geral, os argumentos dedutivos são estéreis. Isto ocorre uma vez que eles não apresentam nenhum conhecimento novo. Assim como já está contida nas premissas, a conclusão nunca vai além delas.
Mesmo que a Ciência não utilize tanto a dedução em suas descobertas (com exceção da matemática), esta forma de raciocínio continua sendo um modelo de rigor dentro da lógica.
A Indução
O argumento indutivo é um raciocínio que geralmente parte de enunciados particulares, singulares e, deles, infere-se um enunciado universal. Ao contrário do argumento dedutivo, a indução pode ir além das premissas —por oferecer novas informações que as premissas não possuíam. Visto isso, fica claro o motivo pelo qual este método é o mais usado pelo pensamento científico.
Através dos argumentos indutivos, as ciências podem descobrir as leis gerais da natureza. A indução, de forma geral, parte de dados da experiência e, com eles, passa a oferecer enunciados universais. Com base em dados particulares do presente as ciências têm a possibilidade de erigir conjecturas sobre o passado e o futuro.
"Os argumentos indutivos, ao contrário do que sucede com os dedutivos, levam a conclusões cujo conteúdo excede os das premissas. E esse traço característico da indução que torna os argumentos indispensáveis para a fundamentação de uma significativa porção dos nossos conhecimentos." (SALMON, 1969, p. 76)
Todavia, o grande problema do processo indutivo é seu caráter probabilístico. Como já enunciado, na dedução a conclusão decorre, necessariamente, das premissas. Por sua vez, na indução isso é impossível, haja vista seu funcionamento lógico de enumerar casos particulares e, por probabilidade, inferir uma verdade universal.
Na indução, a conclusão tem apenas a probabilidade de ser verdadeira, pois não decorre, necessariamente, das premissas: é uma probabilidade que a conclusão seja verdadeira. Do ponto de vista formal, entretanto, o argumento é correto. Contudo, diferentemente da dedução, um argumento indutivo válido pode admitir uma conclusão falsa — ainda que suas premissas sejam verdadeiras. Já quando as premissas de um argumento dedutivo são válidas, a conclusão deve ser verdadeira.
"A idéia básica é esta: na indução, contrariamente ao que sucede na dedução, não estamos certos de que a conclusão será sempre verdadeira, quando as premissas são verdadeiras; podemos, porém, fazer que a conclusão seja verdadeira o mais freqüentemente possível." (SALMON, 1969, p.77)
O raciocínio indutivo nunca possuirá a pretensão de que suas premissas forneçam provas evidentes para a verdade de uma conclusão. Ela pode, apenas, fornecer algumas provas disso. Os argumentos indutivos não são validos nem inválidos (no sentido em que estes termos se aplicam aos argumentos dedutivos).
"Os raciocínios podem, é claro, ser avaliados como melhores ou piores, segundo o grau de verossimilhança ou probabilidade que as premissas confiram às respectivas conclusões." (COPI, 1978, p. 35)
O argumento na Lógica aristotélica
Em sua obra Organon, Aristóteles separa os argumentos em empregados em discussão e empregados em polêmica. são eles:
- Argumentos em empregados em discussão
- instrucionais: os argumentos instrucionais são os que raciocinam dedutivamente a partir dos princípios apropriados a cada ramo do aprendizado, e não a partir de opiniões do interlocutor (pois é necessário que aquele que aprende deva estar convencido das coisas).
- dialéticos: argumentos dialéticos são os que, partindo de opiniões de aceitação geral, deduzem visando estabelecer uma contradição.
- examinacionais: os argumentos examinacionais são aqueles baseados em opiniões sustentadas pelo interlocutor e, necessariamente, conhecidos.
- contenciosos: os argumentos contenciosos são os que deduzem (ou parece deduzir) a partir de opiniões que parecem ser geralmente aceitas — mas não o são realmente.
- Argumentos em empregados em polêmica
- didascálicos: argumento que se baseia em princípios próprios de cada disciplina, e não a partir das opiniões de quem responde.
- dialéticos: argumentos que concluem, a partir de premissas prováveis, a contradição da tese dada.
- críticos: raciocinados a partir de premissas que parecem verdadeiras a quem responde, e que deve conhecer necessariamente o tema que nelas se acha implícito.
- erísticos: argumentos que concluem, ou parecem concluir (a partir de premissas prováveis), na aparência, mas que são na verdade improváveis.
Em Refutações Sofísticas Aristóteles examina os argumentos litigiosos e erísticos ou contenciosos (que ocorrem na polêmica), em que cada parte só tem por interesse vencer a outra parte na disputa. Nesse caso, há cinco modos de vencer: pela refutação, pela falácia, pela opinião extraordinária (ou paradoxo), pelo solecismo e pela redução do interlocutor à redundância (ou dizer a mesma coisa repetidas vezes).
O tema é relevante tanto para a análise retórica quanto para a constituição de uma teoria do conhecimento que ultrapasse sua atual vinculação com a Lógica, pois, para esta, os argumentos litigiosos devem ser afastados. No entanto, caso seja compreendido que as doutrinas ou teorias pedagógicas são máquinas para produzir litígios, então o conhecimento daqueles argumentos faz-se imprescindível.
O argumento nas ciências jurídicas
A Lógica Jurídica tem por objetivo o estudo dos princípios e regras relativos às operações intelectuais efetuadas pelo Jurista na elaboração, apreciação e aplicação do estudo do Direito. Condição e instrumentos necessários, os argumentos são partes essenciais da Lógica Jurídica.
No âmbito do Direito há a composição de um sistema lógico que não confere, necessariamente, com a realidade. Uma idéia pode ser lógica, mas decorrências elaboradas a partir dessa idéia podem não refletir, eventualmente, a realidade.
Há, na lógica jurídica, certa auto-crítica a respeito de sua natureza. Para o Direito, a lógica é uma maneira específica de pensar, ou seja, de organizar o pensamento. O Jurista usa a lógica no cotidiano através de sentenças, petições, pareceres, recursos etc., sabendo que este instrumento racional não é o única nem o mais apropriado (em muitas das situações), mas tem a sua importância. Para que uma inferência (relação premissa-conclusão) tenha caráter lógico, deve-se ser obedecer três princípios basilares:
- Princípio da identidade: afirma que o que é, é; se uma idéia é verdadeira, ela é verdadeira.
- Princípio da não-contradição: nenhuma idéia pode ser falsa e verdadeira ao mesmo tempo.
- Princípio do terceiro excluído: uma idéia ou é verdadeira ou é falsa, não admitindo uma terceira opção.
Em suma, a lógica jurídica não guarda absoluta correspondência com a realidade. Pode se estender a denominação de Lógica Jurídica ao estudo da argumentação jurídica de caráter retórico e ao das regras não estritamente lógicas de interpretação do direito.
Bibliografia
ARISTÓTELES. Organon.
______. Primeiros Analíticos.
______. Segundos Analíticos.
MANOSSO, Radamés. Elementos de Retórica.
Ligações externas
An introduction to teaching logic as a tool
Retirado de "http://ateus.net/wiki/index.php?title=Argumento"
segunda-feira, 7 de abril de 2008
Agile IT Architecture
ABRD mitigates the risk associated with new business rules initiatives by providing a well documented and structured approach for developing rule-based applications. ABRD allows organizations to avoid using ad-hoc processes or having to expend significant time and effort creating their own best practices.
In case you never have a look at EPF, Eclipse Process Framework provides tools for software process engineering to develop methodology. It comes with content knowledge organized in library, and with a tool, EPF Composer, which enables process engineers and managers to implement, deploy, and maintain processes for organizations or individual projects based on the content of the library."
Agile IT Architecture
The purpose of this article is to present an integrated software life cycle for development team who wants to leverage the capabilities offered by technologies such as BPM-BPEL and Business rules management system.
Each new business application development is triggered by a business needs to support or enhance and improve business efficiency. Even with an Agile approach, to trigger the project, architect, business users, project manager and project sponsor have to work together during the Inception phase, to define the business case, the requirements and justifications of the project. Once the project funded, the team may work on specification and requirement documents. I simplify a little here because in reality a lot more documents may be produced, but the goal here is to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the major work that needs to be done for developing the applications. The format of the specification can be user stories, or a more detailed description. (a good reference to write specifications and user case is Alistair Cockburn work ). Specifications are classically managed by a standard SDLC which includes design, build, test, and deploy of working code to the different staging platforms (development, test, or production).
The Agile approach enforces short iterations to deliver quick value to the business. The blue tasks in the diagram below represent a set of iterations that build the core of the business application."
Agile IT Architecture: A Cycle Approach for Business Rule Development
Rule Discovery
Rule Analysis
Rule Authoring
Rule Validation
Rule Deployment
The following diagram represents how the five groups of activities can be executed in a process flow using loops to implement short iterations. The rule set will grow following these cycles to get closer to the outcome expected by the business."
Defining Business Rules ~ What Are They Really? (Abstract and Table of Contents)
"Abstract
Systems analysts have long been able to describe enterprises in terms of the structure of the data those enterprises use and the organization of the functions they perform, but have tended to neglect the constraints under which the enterprise operates. Frequently these are not articulated until it is time to convert them into program code. While rules which are represented by the structure and functions of an enterprise have been documented to a degree, others have not been articulated as well, if at all.
The GUIDE Business Rules Project was organized in November 1993 to carry out that articulation. This paper, the original report of the GUIDE Business Rules Project (now the Business Rules Group), describes a scheme for understanding the nature of business rules and the categories into which they fall. It presents a formal approach for identifying and articulating the rules that define the structure and control the operation of an enterprise.
Table of Contents
The Table of Contents below is intended for readers who wish to load the document one chapter at a time. You may go to each chapter directly from the Table of Contents below or read the document sequentially, from one chapter to the next.
The document is also available as a PDF format document (approximately 175k).
Introduction
Project Scope and Objectives
Overview of the Paper
The Rationale
A Context for Business Rules
Definition of a Business Rule
Categories of Business Rule
Formalizing Business Rules
The Business Rules Conceptual Model
Formulating Business Rules
The Origins of Business Rules -- the Model
Types of Business Rule
Definitions
Structural Assertions
Terms and Facts
Kinds of Term
Kinds of Fact
Base Facts / Derived Facts
Attribute / Participation / Generalization
Definitions
Action Assertions
Action Assertion Classifications
Action Assertion Classes
Action Assertion Types
Controlling vs. Influencing
Definitions
Derivations
Kinds of Derivation
Definitions
Footnotes & Acknowledgments
Footnotes
Acknowledgments
Appendix A: The Complete Model
Appendix B: How to Read a Conceptual Model
Appendix C: An Extended List of Action Assertion Types
Appendix D: Case Study: EU-Rent Car Rentals
Appendix E: Glossary
Appendix F: Bibliography
Go to... Top of page First chapter BRG Home Page
Copyright ©2001, the Business Rules Group. All rights reserved.
sábado, 5 de abril de 2008
RuleML Homepage
Creating and Using Business Rules
"Creating and Using Business Rules
Business rules (or business policies) define and control the structure, operation, and strategy of an organization. Business rules may be formally defined in procedure manuals, contracts, or agreements, or may exist as knowledge or expertise embodied in employees. Business rules are dynamic and subject to change over time, and can be found in all types of applications. Finance and insurance, e-business, transportation, telecommunications, Web-based services, and personalization are just a few of the many business domains that are governed by business rules. Each of these business domains shares the need to convey business strategies, policies, and regulations to information technology (IT) personnel for inclusion into software applications.
Traditional procedural and object-oriented programming languages, such as C, C++, and Microsoft® Visual Basic®, are oriented towards programmers. Even advanced object-oriented languages, such as Java and C#, are still primarily programmers' languages. The traditional software development cycle of design, develop, compile, and test requires substantial time and coordination, and does not enable nonprogrammers to participate in the maintenance of automated business policies. The Business Rules Framework addresses this problem by providing a development environment that allows rapid application creation without the lengthy cycle of traditional application programming. For example, business policies constructed by using this framework can be updated without recompiling and redeploying the associated orchestrations.
The Business Rules Framework is tightly integrated with Microsoft® BizTalk Server 2006, and developers can use the following features to build and manage business rules:
A high-performance rule engine that implements an inference mechanism to evaluate the business rules.
A rich set of application programming interfaces (APIs) for developing rule-based applications.
A graphical user interface, the Business Rule Composer, which developers, business analysts, and administrators can use in various ways to efficiently develop and apply rules and policies.
A seamless integration with BizTalk orchestrations, which enables you to invoke a business policy or a set of business rules from a BizTalk orchestration.
The Rule Engine Deployment Wizard, which enables you to rapidly import or export business rules or the vocabularies used by the rules, as well as to deploy or undeploy these rules.
The business rules (policy) you create by using the Business Rules Framework can be used in an orchestrated business process, as shown in the following figure.
Business Policy
This section provides conceptual information about how you can leverage the Business Rules Framework and use the tools that BizTalk Server 2006 provides to develop business rules.
In This Section
Creating Business Rules
Business Rules Framework Security
Programming with Business Rules Framework
Rule Engine Configuration and Tuning Parameters "
Business Rules Engine
"Business Rules Engine
The Business Rules Framework is a Microsoft .NET-compliant class library. It provides an efficient inference engine that can link highly readable, declarative, semantically rich rules to any business objects (.NET components), XML documents, or database tables. Application developers can build business rules by constructing rules from small building blocks of business logic (small rule sets) that operate on information (facts) contained in .NET objects, database tables, and XML documents. This design pattern promotes code reuse, design simplicity, and modularity of business logic. In addition, the rule engine does not impose on the architecture or design of business applications. In fact, you can add rule technology to a business application by directly invoking the rule engine, or you can have external logic that invokes your business objects without modifying them. In short, the technology enables developers to create and maintain applications with minimal effort.
In planning development of a rule-based application, you first need to determine how rules will fit into your business processes. Your application will create an instance of a policy and supply it with data, or facts, on which to operate. The policy object encapsulates the rule engine and provides a single point of entry through which to run it.
You also will need to plan for the development and testing of your rules design. You must consider how you are going to deploy and update your policies. You will likely want to track the progress of your rule engine's execution and monitor its current state.
Account for the following steps as you plan your rules development:
Plan how to incorporate your rules into your application.
Identify the business logic that you want to represent with rules in your application. The term "business logic" can refer to many things; an example of business logic is "Purchase orders for more than five hundred dollars must be approved by a manager."
Identify data sources for your rule elements. You can optionally define and publish vocabularies (domain-specific nomenclature that represents underlying bindings).
Define rules from vocabulary definitions or directly from data bindings, and from them compose a policy that represents your business logic.
Note
Vocabularies must be published before they can be applied in rules.
Test and debug the policy with sample facts. You can either use the Test Policy functionality in the Business Rule Composer or use Policy or PolicyTester classes to execute from an application, command-line program, or orchestration.
Publish the policy version to the rule store.
Deploy the policy version.
Instantiate and build the short-term fact list in the hosting application. Use the Call Rules shape in an orchestration to execute your business policy or programmatically instantiate a policy version in your hosting application.
Monitor and track rule execution as needed.
Note
The default tracking interceptor works with orchestrations. If your hosting application is not an orchestration, you must write your own tracking interceptor to do this.
In This Section
Rules
Policies
Vocabularies
Business Rules Framework Architecture
Facts
Rule Engine"
sexta-feira, 4 de abril de 2008
Oracle
Esse white paper destaca todas as maneiras como o Banco de Dados Oracle aproveita a plataforma Windows para proporcionar um desempenho superior; como ele se integra ao Microsoft Visual Studio .NET para agilizar o desenvolvimento dos aplicativos; e por que o Banco de Dados Oracle no Windows é a combinação certa para muitas pequenas e médias empresas.
Sendo o primeiro fabricante de banco de dados a lançar um banco de dados relacional no Windows NT e parceiro do programa Visual Studio Industry Partner da Microsoft, a Oracle tem muito a oferecer às pessoas que trabalham em ambiente Windows. Esperamos que estas informações sejam úteis para você avaliar quais soluções fornecerão o melhor valor, o mais alto desempenho e o menor custo.
Clique no botão cinza à direita para baixar o white paper gratuito da Ovum Summit."
