Les livres anglais
4 livres et 3 critiques, dernière mise à jour le 6 juin 2024 , note moyenne : 4.3
- Test-Driven Java Development - Invoke TDD principles for end-to-end application development with Java
- The Unified Software Development Process - The complete guide to the Unified Process from the original designers
- Object-Oriented Thought Process, 2nd edition
- UML Distilled - A Brief Guide to the Standard Object Modeling Language
Détails du livre
Sommaire
Critiques (0)
0 commentaire
Test-Driven Java Development
Invoke TDD principles for end-to-end application development with Java
de Viktor Farcic et Alex Garcia
Public visé :
Débutant
Résumé de l'éditeur
Test-driven development (TDD) is a development approach that relies on a test-first procedure that emphasises writing a test before writing the necessary code, and then refactoring the code to optimize it.
The value of performing TDD with Java, one of the most established programming languages, is to improve the productivity of programmers, the maintainability and performance of code, and develop a deeper understanding of the language and how to employ it effectively.
Starting with the basics of TDD and reasons why its adoption is beneficial, this book will take you from the first steps of TDD with Java until you are confident enough to embrace the practice in your day-to-day routine.
You’ll be guided through setting up tools, frameworks, and the environment you need, and will dive right in to hands-on exercises with the goal of mastering one practice, tool, or framework at a time. You’ll learn about the Red-Green-Refactor procedure, how to write unit tests, and how to use them as executable documentation.
With this book you’ll also discover how to design simple and easily maintainable code, work with mocks, utilise behaviour-driven development, refactor old legacy code, and release a half-finished feature to production with feature toggles.
You will finish this book with a deep understanding of the test-driven development methodology and the confidence to apply it to application programming with Java.
The value of performing TDD with Java, one of the most established programming languages, is to improve the productivity of programmers, the maintainability and performance of code, and develop a deeper understanding of the language and how to employ it effectively.
Starting with the basics of TDD and reasons why its adoption is beneficial, this book will take you from the first steps of TDD with Java until you are confident enough to embrace the practice in your day-to-day routine.
You’ll be guided through setting up tools, frameworks, and the environment you need, and will dive right in to hands-on exercises with the goal of mastering one practice, tool, or framework at a time. You’ll learn about the Red-Green-Refactor procedure, how to write unit tests, and how to use them as executable documentation.
With this book you’ll also discover how to design simple and easily maintainable code, work with mocks, utilise behaviour-driven development, refactor old legacy code, and release a half-finished feature to production with feature toggles.
You will finish this book with a deep understanding of the test-driven development methodology and the confidence to apply it to application programming with Java.
Édition : Packt Publishing - 284 pages, 1re édition, 27 août 2015
ISBN10 : B00YSIM3SC - ISBN13 : B00YSIM3SC
Explore the tools and frameworks required for effective TDD development
Perform the Red-Green-Refactor process efficiently, the pillar around which all other TDD procedures are based
Master effective unit testing in isolation from the rest of your code
Design simple and easily maintainable codes by implementing different techniques
Use mocking frameworks and techniques to easily write and quickly execute tests
Develop an application to implement behaviour-driven development in conjunction with unit testing
Enable and disable features using Feature Toggles
Perform the Red-Green-Refactor process efficiently, the pillar around which all other TDD procedures are based
Master effective unit testing in isolation from the rest of your code
Design simple and easily maintainable codes by implementing different techniques
Use mocking frameworks and techniques to easily write and quickly execute tests
Develop an application to implement behaviour-driven development in conjunction with unit testing
Enable and disable features using Feature Toggles
Aucune critique n'a été faite pour l'instant
Commenter
Signaler un problème
Test-Driven Java Development
Invoke TDD principles for end-to-end application development with Java
Invoke TDD principles for end-to-end application development with Java
Test-driven development (TDD) is a development approach that relies on a test-first procedure that emphasises writing a test before writing the necessary code, and then refactoring the code to optimize it.
The value of performing TDD with Java, one of the most established programming languages, is to improve the productivity of programmers, the maintainability and performance of code, and develop a deeper understanding of the language and how to employ it effectively.
Starting with the basics of TDD and reasons why its adoption is beneficial, this book will take you from the first steps of TDD with Java until you are confident enough to embrace the practice in your day-to-day routine.
You’ll be guided through setting up tools, frameworks, and the environment you need, and will dive right in to hands-on exercises with the goal of mastering one practice, tool, or framework at a time. You’ll learn about the Red-Green-Refactor procedure, how to write unit tests, and how to use them as executable documentation.
With this book you’ll also discover how to design simple and easily maintainable code, work with mocks, utilise behaviour-driven development, refactor old legacy code, and release a half-finished feature to production with feature toggles.
You will finish this book with a deep understanding of the test-driven development methodology and the confidence to apply it to application programming with Java.
[Lire la suite]
The value of performing TDD with Java, one of the most established programming languages, is to improve the productivity of programmers, the maintainability and performance of code, and develop a deeper understanding of the language and how to employ it effectively.
Starting with the basics of TDD and reasons why its adoption is beneficial, this book will take you from the first steps of TDD with Java until you are confident enough to embrace the practice in your day-to-day routine.
You’ll be guided through setting up tools, frameworks, and the environment you need, and will dive right in to hands-on exercises with the goal of mastering one practice, tool, or framework at a time. You’ll learn about the Red-Green-Refactor procedure, how to write unit tests, and how to use them as executable documentation.
With this book you’ll also discover how to design simple and easily maintainable code, work with mocks, utilise behaviour-driven development, refactor old legacy code, and release a half-finished feature to production with feature toggles.
You will finish this book with a deep understanding of the test-driven development methodology and the confidence to apply it to application programming with Java.
[Lire la suite]
- Avez-vous lu ce livre ou pensez-vous le lire ?
- Souhaitez-vous ajouter une critique de ce livre sur la page de la rubrique ?
- Avez-vous un commentaire à faire ?
Détails du livre
Sommaire
Critiques (1)
0 commentaire
The Unified Software Development Process
The complete guide to the Unified Process from the original designers
de Ivar Jacobson, Grady Booch, James Rumbaugh
Traducteurs : aucun
Public visé :
Expert
Résumé de l'éditeur
This landmark book provides a thorough overview of the Unified Process for software development, with a practical focus on modeling using the Unified Modeling Language (UML). The Unified Process goes beyond mere object-oriented analysis and design to spell out a proven family of techniques that supports the complete software development life cycle. The result is a component-based process that is use-case driven, architecture-centric, iterative, and incremental.
The Unified Process takes full advantage of the industry-standard Unified Modeling Language. This book demonstrates how the notation and process complement one another, using UML models to illustrate the new process in action. The authors clearly describe the semantics and notation of the different higher-level constructs used in the models. Constructs such as use cases, actors, subsystems, classes, interfaces, active classes, processes, threads, nodes, and most relations are described in the context of a model. Object technology practitioners and software engineers familiar with the authors' past work will appreciate The Unified Software Development Process as a useful means of learning the current best practices in software development.
The Unified Process takes full advantage of the industry-standard Unified Modeling Language. This book demonstrates how the notation and process complement one another, using UML models to illustrate the new process in action. The authors clearly describe the semantics and notation of the different higher-level constructs used in the models. Constructs such as use cases, actors, subsystems, classes, interfaces, active classes, processes, threads, nodes, and most relations are described in the context of a model. Object technology practitioners and software engineers familiar with the authors' past work will appreciate The Unified Software Development Process as a useful means of learning the current best practices in software development.
Édition : Addison-Wesley Professional - 512 pages, 1re édition, 4 février 1999
ISBN10 : 0321822005 - ISBN13 : 9780321822000
Ce livre présente la réelle méthode chapeautant le langage UML.
Preface.
I. THE UNIFIED SOFTWARE DEVELOPMENT PROCESS.
1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental.
The Unified Process in a Nutshell.The Unified Process Is Use-Case Driven.The Unified Process Is Architecture-Centric.The Unified Process Is Iterative and Incremental.The Life of the Unified Process.The Product.Phases within a Cycle.An Integrated Process.2. The Four Ps: People, Project, Product, and Process in Software Development.
People Are Crucial.Development Processes Affect People.Roles Will Change.Turning “Resources” into “Workers.”Projects Make the Product.Product Is More Than Code.What Is a Software System?Artifacts.A System Has a Collection of Models.What Is a Model?Each Model Is a Self-Contained View of the System.Inside a Model.Relationships between Models.Process Directs Projects.Process: A Template.Related Activities Make Up Workflows.Specializing Process.Merits of Process.Tools Are Integral to Process.Tools Impact Process.Process Drives Tools.Balance Process and Tools.Visual Modeling Supports UML.Tools Support the Whole Life Cycle.References.3. A Use-Case-Driven Process.
Use-Case-Driven Development in Brief.Why Use Cases?To Capture the Value Adding Requirements.To Drive the Process.To Devise the Architecture and More...Capturing the Use Cases.The Use-Case Model Represents the Functional Requirements.Actors Are the Environment of the System.Use Cases Specify the System.Analysis, Design, and Implementation to Realize the Use Cases.Creating the Analysis Model from the Use Cases.Each Class Must Fulfill All Its Collaboration Roles.Creating the Design Model from the Analysis Model.Subsystems Group Classes.Creating the Implementation Model from the Design Model.Testing the Use Cases.Summing Up.References.4. An Architecture-Centric Process
Architecture in Brief.Why We Need Architecture.Understanding the System.Organizing Development.Fostering Reuse.Evolving the System.Use Cases and Architecture.The Steps to an Architecture.The Architecture Baseline Is a “Small, Skinny” System.Using Architecture Patterns.Describing Architecture.The Architect Creates the Architecture.Finally, an Architecture Description!The Architectural View of the Use-Case Model.The Architectural View of the Design Model.The Architectural View of the Deployment Model.The Architectural View of the Implementation Model.Three Interesting Concepts.What Is Architecture?How Is It Obtained?How Is It Described?References.5. An Iterative and Incremental Process.
Iterative and Incremental in Brief.Develop in Small Steps.What Iteration Is Not.Why Iterative and Incremental Development?Mitigating Risks.Getting a Robust Architecture.Handling Changing Requirements.Allowing for Tactical Changes.Achieving Continuous Integration.Attaining Early Learning.The Iterative Approach is Risk-Driven.Iterations Alleviate Technical Risks.Management Is Responsible for Nontechnical Risks.Dealing with Risks.The Generic Iteration.What an Iteration Is.Planning the Iterations.Sequencing the Iterations.The Result of an Iteration Is an Increment.Iterations over the Life Cycle.Models Evolve from Iterations.Iterations Challenge the Organization.References.
II. THE CORE WORKFLOWS.
6. Requirements Capture: From Vision to Requirements.
Why Requirements Capture Is Difficult.The Purpose of the Requirements Workflow.Overview of Requirements Capture.The Role of Requirements in the Software Life Cycle.Understanding the System Context Using a Domain Model.What Is a Domain Model?Developing a Domain Model.Use of the Domain Model.Understanding the System Context Using a Business Model.What Is a Business Model?How to Develop a Business Model.Find Use Cases from a Business Model.Supplementary Requirements.Summary.References.7. Capturing the Requirements as Use Cases.
Introduction.Artifacts.Artifact: Use-Case Model.Artifact: Actor.Use Case.Artifact: Architecture Description (View of the Use-Case Model).Artifact: Glossary.Artifact: User-Interface Prototype.Workers.Worker: System Analyst.Worker: Use-Case Specifier.User-Interface Designer.Worker: Architect.Workflow.Activity: Find Actors and Use Cases.Activity: Prioritize Use Cases.Activity: Detail a Use Case.Activity: Prototype User Interface.Activity: Structure the Use-Case Model.Summary of the Requirements Workflow.References.8. Analysis.
Introduction.Analysis in Brief.Why Analysis Is not Design or Implementation.The Purpose of Analysis: Summary.Concrete Examples of When to Employ Analysis.The Role of Analysis in the Software Life Cycle.Artifacts.Artifact: Analysis Model.Artifact: Analysis Class.Artifact: Use-Case Realization—Analysis.Artifact: Analysis Package.Artifact: Architecture Description (View of the Analysis Model).Workers.Worker: Architect.Worker: Use-Case Engineer.Worker: Component Engineer.Workflow.Activity: Architectural Analysis.Activity: Analyze a Use Case.Activity: Analyze a Class.Activity: Analyze a Package.Summary of Analysis.References.9. Design.
Introduction.The Role of Design in the Software Life Cycle.Artifacts.Artifact: Design Model.Artifact: Design Class.Artifact: Use-Case Realization—Design.Artifact: Design Subsystem.Artifact: Interface.Artifact: Architecture Description (View of the Design Model).Artifact: Deployment Model.Artifact: Architecture Description (View of the Deployment Model).Workers.Worker: Architect.Worker: Use-Case Engineer.Worker: Component Engineer.Workflow.Activity: Architectural Design.Activity: Design a Use Case.Activity: Design a Class.Activity: Design a Subsystem.Summary of Design.References.10. Implementation.
Introduction.The Role of Implementation in the Software Life Cycle.Artifacts.Artifact: Implementation Model.Artifact: Component.Artifact: Implementation Subsystem.Artifact: Interface.Artifact: Architecture Description (View of the Implementation Model).Artifact: Integration Build Plan.Workers.Worker: Architect.Worker: Component Engineer.Worker: System Integrator.Workflow.Activity: Architectural Implementation.Activity: Integrate System.Activity: Implement a Subsystem.Activity: Implement a Class.Activity: Perform Unit Test.Summary of Implementation.References.11. Test.
Introduction.The Role of Testing in the Software Life Cycle.Artifacts.Artifact: Test Model.Artifact: Test Case.Artifact: Test Procedure.Artifact: Test Component.Artifact: Plan Test.Artifact: Defect.Artifact: Evaluate Test.Workers.Worker: Test Designer.Worker: Component Engineer.Worker: Integration Tester.Worker: System Tester.Workflow.Activity: Plan Test.Activity: Design Test.Activity: Implement Test.Activity: Perform Integration Test.Activity: Perform System Test.Activity: Evaluate Test.Summary of Testing.References.
III. ITERATIVE AND INCREMENTAL DEVELOPMENT.
12. The Generic Iteration Workflow.
The Need for Balance.The Phases Are the First Division of Work.Inception Phase Establishes Feasibility.Elaboration Phase Focuses on “Do-Ability.”Construction Phase Builds the System.Transition Phase Moves into the User Environment.The Generic Iteration Revisited.Core Workflows Repeat in Each Iteration.Workers Participate in the Workflows.Planning Precedes Doing.Plan the Four Phases.Plan the Iterations.Think Long Term.Plan the Evaluation Criteria.Risks Affect Project Planning.Manage a Risk List.Risks Affect the Iteration Plan.Schedule Risk Action.Use-Case Prioritization.Risks Specific to a Particular Product.Risk of Not Getting the Architecture Right.Risk of Not Getting Requirements Right.Resources Needed.Projects Differ Widely.A Typical Project Looks Like This.Complex Projects Have Greater Needs.New Product Line Calls for Experience.Paying the Cost of the Resources Used.Assess the Iterations and Phases.Criteria Not Achieved.The Criteria Themselves.The Next Iteration.Evolution of the Model Set.13. Inception Launches the Project.
The Inception Phase in Brief.Early in the Inception Phase.Before the Inception Phase Begins.Planning the Inception Phase.Expanding the System Vision.Setting the Evaluation Criteria.The Archetypal Inception Iteration Workflow.Introduction to the Five Core Workflows.Fitting the Project into the Development Environment.Finding Critical Risks.Execute the Core Workflows, Requirements to Test.Capture the Requirements.Analysis.Design.Test.Make the Initial Business Case.Outline Business Bid.Estimate Return on Investment.Assess the Iteration(s) in the Inception Phase.Planning the Elaboration Phase.The Deliverables for the Inception Phase.14. The Elaboration Phase Makes the Architectural Baseline.
The Elaboration Phase in Brief.Early in the Elaboration Phase.Planning the Elaboration Phase.Building the Team.Modifying the Development Environment.Setting Evaluation Criteria.The Archetypal Elaboration Iteration Workflow.Capture and Refine Most of the Requirements.Develop the Architectural Baseline.Iterate While the Team Is Small.Execute the Core Workflows—Requirements to Test.Capture the Requirements.Analysis.Design.Implementation.Test.Make the Business Case.Prepare the Business Bid.Update Return on Investment.Assess the Iterations in the Elaboration Phase.Planning the Construction Phase.The Key Deliverables.15. Construction Leads to Initial Operational Capability.
The Construction Phase in Brief.Early in the Construction Phase.Staffing the Phase.Setting the Evaluation Criteria.The Archetypal Construction Iteration Workflow.Execute the Core Workflows—Requirements to Testing.Requirements.Analysis.Design.Implementation.Test.Controlling the Business Case.Assess the Iterations and the Construction Phase.Planning the Transition Phase.The Key Deliverables.16. Transition Completes Product Release.
The Transition Phase in Brief.Early in the Transition Phase.Planning the Transition Phase.Staffing the Transition Phase.Setting the Evaluation Criteria.The Core Workflows Play a Small Role in this Phase.What We Do in the Transition Phase.Getting the Beta Release Out.Installing the Beta Release.Responding to the Test Results.Adapting the Product to Varied User Environments.Completing the Artifacts.When Does the Project End?Completing the Business Case.Controlling Progress.Review of the Business Plan.Assess the Transition Phase.Assess the Iterations and the Phase.Postmortem of the Project.Planning the Next Release or Generation.The Key Deliverables.17. Making the Unified Process Work.
The Unified Process Helps You Deal with Complexity.The Life Cycle Objectives.The Life Cycle Architecture.Initial Operational Capability.Product Release.The Major Themes.Management Leads Conversion to Unified Process.The Case for Action.The Reengineering Directive Persuades.Implementing the Transition.Specializing the Unified Process.Tailoring the Process.Filling in the Process Framework.Relate to the Broader Community.Get the Benefits of the Unified Process.References.Appendix A: Overview of the UML.
Introduction.Vocabulary.Extensibility Mechanisms.Graphical Notation.Structural Things.Behavioral Things.Grouping Things.Annotational Things.Dependency Relationships.Association Relationships.Generalization Relationships.Extensibility Mechanisms.Glossary of Terms.References.Appendix B: The Unified Process-Specific Extensions of the UML.
Introduction.Stereotypes.Tagged Values.Graphical Notation.References.Appendix C: General Glossary.
Introduction.Terms.Index.
I. THE UNIFIED SOFTWARE DEVELOPMENT PROCESS.
1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental.
The Unified Process in a Nutshell.The Unified Process Is Use-Case Driven.The Unified Process Is Architecture-Centric.The Unified Process Is Iterative and Incremental.The Life of the Unified Process.The Product.Phases within a Cycle.An Integrated Process.2. The Four Ps: People, Project, Product, and Process in Software Development.
People Are Crucial.Development Processes Affect People.Roles Will Change.Turning “Resources” into “Workers.”Projects Make the Product.Product Is More Than Code.What Is a Software System?Artifacts.A System Has a Collection of Models.What Is a Model?Each Model Is a Self-Contained View of the System.Inside a Model.Relationships between Models.Process Directs Projects.Process: A Template.Related Activities Make Up Workflows.Specializing Process.Merits of Process.Tools Are Integral to Process.Tools Impact Process.Process Drives Tools.Balance Process and Tools.Visual Modeling Supports UML.Tools Support the Whole Life Cycle.References.3. A Use-Case-Driven Process.
Use-Case-Driven Development in Brief.Why Use Cases?To Capture the Value Adding Requirements.To Drive the Process.To Devise the Architecture and More...Capturing the Use Cases.The Use-Case Model Represents the Functional Requirements.Actors Are the Environment of the System.Use Cases Specify the System.Analysis, Design, and Implementation to Realize the Use Cases.Creating the Analysis Model from the Use Cases.Each Class Must Fulfill All Its Collaboration Roles.Creating the Design Model from the Analysis Model.Subsystems Group Classes.Creating the Implementation Model from the Design Model.Testing the Use Cases.Summing Up.References.4. An Architecture-Centric Process
Architecture in Brief.Why We Need Architecture.Understanding the System.Organizing Development.Fostering Reuse.Evolving the System.Use Cases and Architecture.The Steps to an Architecture.The Architecture Baseline Is a “Small, Skinny” System.Using Architecture Patterns.Describing Architecture.The Architect Creates the Architecture.Finally, an Architecture Description!The Architectural View of the Use-Case Model.The Architectural View of the Design Model.The Architectural View of the Deployment Model.The Architectural View of the Implementation Model.Three Interesting Concepts.What Is Architecture?How Is It Obtained?How Is It Described?References.5. An Iterative and Incremental Process.
Iterative and Incremental in Brief.Develop in Small Steps.What Iteration Is Not.Why Iterative and Incremental Development?Mitigating Risks.Getting a Robust Architecture.Handling Changing Requirements.Allowing for Tactical Changes.Achieving Continuous Integration.Attaining Early Learning.The Iterative Approach is Risk-Driven.Iterations Alleviate Technical Risks.Management Is Responsible for Nontechnical Risks.Dealing with Risks.The Generic Iteration.What an Iteration Is.Planning the Iterations.Sequencing the Iterations.The Result of an Iteration Is an Increment.Iterations over the Life Cycle.Models Evolve from Iterations.Iterations Challenge the Organization.References.
II. THE CORE WORKFLOWS.
6. Requirements Capture: From Vision to Requirements.
Why Requirements Capture Is Difficult.The Purpose of the Requirements Workflow.Overview of Requirements Capture.The Role of Requirements in the Software Life Cycle.Understanding the System Context Using a Domain Model.What Is a Domain Model?Developing a Domain Model.Use of the Domain Model.Understanding the System Context Using a Business Model.What Is a Business Model?How to Develop a Business Model.Find Use Cases from a Business Model.Supplementary Requirements.Summary.References.7. Capturing the Requirements as Use Cases.
Introduction.Artifacts.Artifact: Use-Case Model.Artifact: Actor.Use Case.Artifact: Architecture Description (View of the Use-Case Model).Artifact: Glossary.Artifact: User-Interface Prototype.Workers.Worker: System Analyst.Worker: Use-Case Specifier.User-Interface Designer.Worker: Architect.Workflow.Activity: Find Actors and Use Cases.Activity: Prioritize Use Cases.Activity: Detail a Use Case.Activity: Prototype User Interface.Activity: Structure the Use-Case Model.Summary of the Requirements Workflow.References.8. Analysis.
Introduction.Analysis in Brief.Why Analysis Is not Design or Implementation.The Purpose of Analysis: Summary.Concrete Examples of When to Employ Analysis.The Role of Analysis in the Software Life Cycle.Artifacts.Artifact: Analysis Model.Artifact: Analysis Class.Artifact: Use-Case Realization—Analysis.Artifact: Analysis Package.Artifact: Architecture Description (View of the Analysis Model).Workers.Worker: Architect.Worker: Use-Case Engineer.Worker: Component Engineer.Workflow.Activity: Architectural Analysis.Activity: Analyze a Use Case.Activity: Analyze a Class.Activity: Analyze a Package.Summary of Analysis.References.9. Design.
Introduction.The Role of Design in the Software Life Cycle.Artifacts.Artifact: Design Model.Artifact: Design Class.Artifact: Use-Case Realization—Design.Artifact: Design Subsystem.Artifact: Interface.Artifact: Architecture Description (View of the Design Model).Artifact: Deployment Model.Artifact: Architecture Description (View of the Deployment Model).Workers.Worker: Architect.Worker: Use-Case Engineer.Worker: Component Engineer.Workflow.Activity: Architectural Design.Activity: Design a Use Case.Activity: Design a Class.Activity: Design a Subsystem.Summary of Design.References.10. Implementation.
Introduction.The Role of Implementation in the Software Life Cycle.Artifacts.Artifact: Implementation Model.Artifact: Component.Artifact: Implementation Subsystem.Artifact: Interface.Artifact: Architecture Description (View of the Implementation Model).Artifact: Integration Build Plan.Workers.Worker: Architect.Worker: Component Engineer.Worker: System Integrator.Workflow.Activity: Architectural Implementation.Activity: Integrate System.Activity: Implement a Subsystem.Activity: Implement a Class.Activity: Perform Unit Test.Summary of Implementation.References.11. Test.
Introduction.The Role of Testing in the Software Life Cycle.Artifacts.Artifact: Test Model.Artifact: Test Case.Artifact: Test Procedure.Artifact: Test Component.Artifact: Plan Test.Artifact: Defect.Artifact: Evaluate Test.Workers.Worker: Test Designer.Worker: Component Engineer.Worker: Integration Tester.Worker: System Tester.Workflow.Activity: Plan Test.Activity: Design Test.Activity: Implement Test.Activity: Perform Integration Test.Activity: Perform System Test.Activity: Evaluate Test.Summary of Testing.References.
III. ITERATIVE AND INCREMENTAL DEVELOPMENT.
12. The Generic Iteration Workflow.
The Need for Balance.The Phases Are the First Division of Work.Inception Phase Establishes Feasibility.Elaboration Phase Focuses on “Do-Ability.”Construction Phase Builds the System.Transition Phase Moves into the User Environment.The Generic Iteration Revisited.Core Workflows Repeat in Each Iteration.Workers Participate in the Workflows.Planning Precedes Doing.Plan the Four Phases.Plan the Iterations.Think Long Term.Plan the Evaluation Criteria.Risks Affect Project Planning.Manage a Risk List.Risks Affect the Iteration Plan.Schedule Risk Action.Use-Case Prioritization.Risks Specific to a Particular Product.Risk of Not Getting the Architecture Right.Risk of Not Getting Requirements Right.Resources Needed.Projects Differ Widely.A Typical Project Looks Like This.Complex Projects Have Greater Needs.New Product Line Calls for Experience.Paying the Cost of the Resources Used.Assess the Iterations and Phases.Criteria Not Achieved.The Criteria Themselves.The Next Iteration.Evolution of the Model Set.13. Inception Launches the Project.
The Inception Phase in Brief.Early in the Inception Phase.Before the Inception Phase Begins.Planning the Inception Phase.Expanding the System Vision.Setting the Evaluation Criteria.The Archetypal Inception Iteration Workflow.Introduction to the Five Core Workflows.Fitting the Project into the Development Environment.Finding Critical Risks.Execute the Core Workflows, Requirements to Test.Capture the Requirements.Analysis.Design.Test.Make the Initial Business Case.Outline Business Bid.Estimate Return on Investment.Assess the Iteration(s) in the Inception Phase.Planning the Elaboration Phase.The Deliverables for the Inception Phase.14. The Elaboration Phase Makes the Architectural Baseline.
The Elaboration Phase in Brief.Early in the Elaboration Phase.Planning the Elaboration Phase.Building the Team.Modifying the Development Environment.Setting Evaluation Criteria.The Archetypal Elaboration Iteration Workflow.Capture and Refine Most of the Requirements.Develop the Architectural Baseline.Iterate While the Team Is Small.Execute the Core Workflows—Requirements to Test.Capture the Requirements.Analysis.Design.Implementation.Test.Make the Business Case.Prepare the Business Bid.Update Return on Investment.Assess the Iterations in the Elaboration Phase.Planning the Construction Phase.The Key Deliverables.15. Construction Leads to Initial Operational Capability.
The Construction Phase in Brief.Early in the Construction Phase.Staffing the Phase.Setting the Evaluation Criteria.The Archetypal Construction Iteration Workflow.Execute the Core Workflows—Requirements to Testing.Requirements.Analysis.Design.Implementation.Test.Controlling the Business Case.Assess the Iterations and the Construction Phase.Planning the Transition Phase.The Key Deliverables.16. Transition Completes Product Release.
The Transition Phase in Brief.Early in the Transition Phase.Planning the Transition Phase.Staffing the Transition Phase.Setting the Evaluation Criteria.The Core Workflows Play a Small Role in this Phase.What We Do in the Transition Phase.Getting the Beta Release Out.Installing the Beta Release.Responding to the Test Results.Adapting the Product to Varied User Environments.Completing the Artifacts.When Does the Project End?Completing the Business Case.Controlling Progress.Review of the Business Plan.Assess the Transition Phase.Assess the Iterations and the Phase.Postmortem of the Project.Planning the Next Release or Generation.The Key Deliverables.17. Making the Unified Process Work.
The Unified Process Helps You Deal with Complexity.The Life Cycle Objectives.The Life Cycle Architecture.Initial Operational Capability.Product Release.The Major Themes.Management Leads Conversion to Unified Process.The Case for Action.The Reengineering Directive Persuades.Implementing the Transition.Specializing the Unified Process.Tailoring the Process.Filling in the Process Framework.Relate to the Broader Community.Get the Benefits of the Unified Process.References.Appendix A: Overview of the UML.
Introduction.Vocabulary.Extensibility Mechanisms.Graphical Notation.Structural Things.Behavioral Things.Grouping Things.Annotational Things.Dependency Relationships.Association Relationships.Generalization Relationships.Extensibility Mechanisms.Glossary of Terms.References.Appendix B: The Unified Process-Specific Extensions of the UML.
Introduction.Stereotypes.Tagged Values.Graphical Notation.References.Appendix C: General Glossary.
Introduction.Terms.Index.
Je vais me contenter de faire un commentaire sur sa thématique, et des pages que j'ai parcourues, contrasté par une dialectique avec l'usage courant quasi aveugle d'UML.
Le gros problème de l'orienté objet, à mon sens, c'est que l'objet n'est pas même un concept, et le Big Bug d'UML, en tant que simple langage, c'est que chaque developpeur l'utilise un peu à sa sauce... c'est à dire en commençant un peu où bon lui semble (même si les cas d'utilisation semblent en général un bon début) et en finissant sur un schéma X - sans quasiment jamais avoir exploité tous les types de modèles UML - qui sont, il est vrai, plutôt nombreux.
Le livre est écrit par des personnes ayant tantôt travaillé pour l'Armée états-unienne, tantôt pour IBM: accrochez-vous.
Il faut le dire, le livre a un ratio texte/schéma qui penche largement en faveur du texte. Je comprends que c'est une méthode, mais une hiérarchie des modèles UML, ou même le méta-model d'UML - qui à ma connaissance existe (je l'avais téléchargé mais je ne sais plus où il est) - n'y apparaissent pas en tant que modèles (même si a fortiori ils sont décrits par le texte).
J'ai entrevu les évaluations Amazon.com, et la plus pertinente me semble être celle qui est intitulée "Dry text" (texte sec), qui rejoint mon estimation du ratio texte/schémas; un peu dommage qu'un livre qui est censé offrir une méta-considération sur une modélisation exploite tant ce mode grandement linéaire (texte).
Mais peut-être est-ce parce que la tentative d'encapsuler UML dans une généralisation, aurait nécessité l'emploi d'une sorte d'ERP. (Pour donner une image.)
De ce que je comprends jusqu'à ce jour, UML est arrivé pour proposer une méthode plus "agile" qu'un Merise ou autre approche en cascade; problème, ses schéma les plus techniques restent opaques pour le non-initié - et par là constitue peut-être une étape précédant BPMN?
En tous les cas, même si le texte est quantitativement lourd, il reste compréhensible et bien écrit. On ne pourra pas (comme l'on ne peut actuellement pas, d'ailleurs, puisqu'on ne le fait pas) exiger de chaque développeur une lecture aussi titanesque, et par là s'agit-il sans doute d'une faiblesse de l'ouvrage, qui - donc - n'a pas su se reposer sur le méta-modèle.
De par la méthode qu'il propose réellement de faire découvrir, cet ouvrage reste selon moi l'éclairement indispensable à UML (qui ne devrait théoriquement même pas être utilisé sans la méthode) - et devrait instamment constituer une lecture imposée à tous les chefs de projets en développement, qui seraient bien inspirés d'en faire bénéficier leurs subalternes.
C'est une idée confortée par mon impression selon laquelle l'UML - comme plus généralement l'orienté objet, sont une porte ouverte sur le "tout et n'importe quoi", au cas où ils sont implémentés sans recours à cette méthode.
Je donne néanmoins la note maximale - car il vaut mieux bénéficier de cette méthode que de ne pas en avoir - et parce qu'elle me paraît indispensable. Le lecteur consciencieux pensera à chercher le méta-modèle d'UML en complément à cette lecture.
Point fort: Méthode vitale à UML
Points faibles: Le ratio texte/schémas va beaucoup trop en faveur du texte, titanesque. En particulier, le méta-modèle d'UML, qui aurait pu constituer l'allégement
Le gros problème de l'orienté objet, à mon sens, c'est que l'objet n'est pas même un concept, et le Big Bug d'UML, en tant que simple langage, c'est que chaque developpeur l'utilise un peu à sa sauce... c'est à dire en commençant un peu où bon lui semble (même si les cas d'utilisation semblent en général un bon début) et en finissant sur un schéma X - sans quasiment jamais avoir exploité tous les types de modèles UML - qui sont, il est vrai, plutôt nombreux.
Le livre est écrit par des personnes ayant tantôt travaillé pour l'Armée états-unienne, tantôt pour IBM: accrochez-vous.
Il faut le dire, le livre a un ratio texte/schéma qui penche largement en faveur du texte. Je comprends que c'est une méthode, mais une hiérarchie des modèles UML, ou même le méta-model d'UML - qui à ma connaissance existe (je l'avais téléchargé mais je ne sais plus où il est) - n'y apparaissent pas en tant que modèles (même si a fortiori ils sont décrits par le texte).
J'ai entrevu les évaluations Amazon.com, et la plus pertinente me semble être celle qui est intitulée "Dry text" (texte sec), qui rejoint mon estimation du ratio texte/schémas; un peu dommage qu'un livre qui est censé offrir une méta-considération sur une modélisation exploite tant ce mode grandement linéaire (texte).
Mais peut-être est-ce parce que la tentative d'encapsuler UML dans une généralisation, aurait nécessité l'emploi d'une sorte d'ERP. (Pour donner une image.)
De ce que je comprends jusqu'à ce jour, UML est arrivé pour proposer une méthode plus "agile" qu'un Merise ou autre approche en cascade; problème, ses schéma les plus techniques restent opaques pour le non-initié - et par là constitue peut-être une étape précédant BPMN?
En tous les cas, même si le texte est quantitativement lourd, il reste compréhensible et bien écrit. On ne pourra pas (comme l'on ne peut actuellement pas, d'ailleurs, puisqu'on ne le fait pas) exiger de chaque développeur une lecture aussi titanesque, et par là s'agit-il sans doute d'une faiblesse de l'ouvrage, qui - donc - n'a pas su se reposer sur le méta-modèle.
De par la méthode qu'il propose réellement de faire découvrir, cet ouvrage reste selon moi l'éclairement indispensable à UML (qui ne devrait théoriquement même pas être utilisé sans la méthode) - et devrait instamment constituer une lecture imposée à tous les chefs de projets en développement, qui seraient bien inspirés d'en faire bénéficier leurs subalternes.
C'est une idée confortée par mon impression selon laquelle l'UML - comme plus généralement l'orienté objet, sont une porte ouverte sur le "tout et n'importe quoi", au cas où ils sont implémentés sans recours à cette méthode.
Je donne néanmoins la note maximale - car il vaut mieux bénéficier de cette méthode que de ne pas en avoir - et parce qu'elle me paraît indispensable. Le lecteur consciencieux pensera à chercher le méta-modèle d'UML en complément à cette lecture.
Point fort: Méthode vitale à UML Points faibles: Le ratio texte/schémas va beaucoup trop en faveur du texte, titanesque. En particulier, le méta-modèle d'UML, qui aurait pu constituer l'allégement Commenter
Signaler un problème
The Unified Software Development Process
The complete guide to the Unified Process from the original designers
The complete guide to the Unified Process from the original designers
This landmark book provides a thorough overview of the Unified Process for software development, with a practical focus on modeling using the Unified Modeling Language (UML). The Unified Process goes beyond mere object-oriented analysis and design to spell out a proven family of techniques that supports the complete software development life cycle. The result is a component-based process that is use-case driven, architecture-centric, iterative, and incremental.
The Unified Process takes full advantage of the industry-standard Unified Modeling Language. This book demonstrates how the notation and process complement one another, using UML models to illustrate the new process in action. The authors clearly describe the semantics and notation of the different higher-level constructs used in the models. Constructs such as use cases, actors, subsystems, classes, interfaces, active classes, processes, threads, nodes, and most relations are described in the context of a model. Object technology practitioners and software engineers familiar with the authors' past work will appreciate The Unified Software Development Process as a useful means of learning the current best practices in software development.
[Lire la suite]
The Unified Process takes full advantage of the industry-standard Unified Modeling Language. This book demonstrates how the notation and process complement one another, using UML models to illustrate the new process in action. The authors clearly describe the semantics and notation of the different higher-level constructs used in the models. Constructs such as use cases, actors, subsystems, classes, interfaces, active classes, processes, threads, nodes, and most relations are described in the context of a model. Object technology practitioners and software engineers familiar with the authors' past work will appreciate The Unified Software Development Process as a useful means of learning the current best practices in software development.
[Lire la suite]
- Avez-vous lu ce livre ou pensez-vous le lire ?
- Souhaitez-vous ajouter une critique de ce livre sur la page de la rubrique ?
- Avez-vous un commentaire à faire ?
Détails du livre
Sommaire
Critiques (1)
0 commentaire
Object-Oriented Thought Process, 2nd edition
de Matt Weisfeld
Public visé :
Débutant
Résumé de l'éditeur
By the Professional, for the Professional!
The Object-Oriented Thought Process is a concise and readable primer.
Matt Weisfeld's years of programming, teaching, and writing have given him a flair for presenting highly technical topics in a clear and interesting manner. He is able to blend abstract concepts with ingenious examples and clear illustrations to quickly teach powerful OOP techniques.
The code examples are written in Java and UML but are designed in such a way that a reader with no previous experience will still understand them.
The Object-Oriented Thought Process is a clear and accessible alternative to the often dry and overly dense books available on the market today.
Matt Weisfeld has 18 years of software development and project management experience in COBOL, Pascal, C, C++, Smalltalk, and Java. He has taught programming classes for more than 10 years and has been published extensively in leading industry magazines, including Dr. Dobb's and Java Report including many more!
A concise but complete introduction to object-oriented concepts with code examples in Java and UML.
Excellent primer for professional developers moving to object-oriented languages, as well as CS students.
The Object-Oriented Thought Process is a concise and readable primer.
Matt Weisfeld's years of programming, teaching, and writing have given him a flair for presenting highly technical topics in a clear and interesting manner. He is able to blend abstract concepts with ingenious examples and clear illustrations to quickly teach powerful OOP techniques.
The code examples are written in Java and UML but are designed in such a way that a reader with no previous experience will still understand them.
The Object-Oriented Thought Process is a clear and accessible alternative to the often dry and overly dense books available on the market today.
Matt Weisfeld has 18 years of software development and project management experience in COBOL, Pascal, C, C++, Smalltalk, and Java. He has taught programming classes for more than 10 years and has been published extensively in leading industry magazines, including Dr. Dobb's and Java Report including many more!
A concise but complete introduction to object-oriented concepts with code examples in Java and UML.
Excellent primer for professional developers moving to object-oriented languages, as well as CS students.
Édition : Sams Publishing - 304 pages, 2e édition, 1er décembre 2003
ISBN10 : 0672326116 - ISBN13 : 9780672326110
- Introduction to Object-Oriented Concepts
- How to Think in Terms of Objects
- Advanced Object-Oriented Concepts
- The Anatomy of a Class
- Class Design Guidelines
- Object-Oriented Modeling
- Designing with Objects
- Mastering Inheritance and Composition
- Frameworks and Reuse: Interfaces and Abstract Classes
- Building Objects
- Patterns
- XML
- Objects and the Net
- Objects and the Enterprise
- Objects and Databases
À mon avis un ouvrage à lire absolument pour comprendre les concepts objets, avant de parcourir des ouvrages plus spécifiques du genre "Object-Oriented Design in Java" ou "Thinking in C++". Même si les exemples dans cet ouvrage sont écrits en java, les explications sont applicables a tous les langages OO (C++, C#, ...)
Ce livre donne les "clés" pour modéliser et implémenter un logiciel dans un langage Objet. Une mention spéciale pour le chapitre 6 où l'auteur fait l'analyse et la conception d'un jeu de black-jack en partant de la règle du jeu (description textuelle) pour finir aux diagrammes UML en utilisant la méthode des CRC-Cards.
Ce livre donne les "clés" pour modéliser et implémenter un logiciel dans un langage Objet. Une mention spéciale pour le chapitre 6 où l'auteur fait l'analyse et la conception d'un jeu de black-jack en partant de la règle du jeu (description textuelle) pour finir aux diagrammes UML en utilisant la méthode des CRC-Cards.
Commenter
Signaler un problème
Object-Oriented Thought Process, 2nd edition
By the Professional, for the Professional!
The Object-Oriented Thought Process is a concise and readable primer.
Matt Weisfeld's years of programming, teaching, and writing have given him a flair for presenting highly technical topics in a clear and interesting manner. He is able to blend abstract concepts with ingenious examples and clear illustrations to quickly teach powerful OOP techniques.
The code examples are written in Java and UML but are designed in such a way that a reader with no previous experience will still understand them.
The Object-Oriented Thought Process is a clear and accessible alternative to the often dry and overly dense books available on the market today.
Matt Weisfeld has 18 years of software development and project management experience in COBOL, Pascal, C, C++, Smalltalk, and Java. He has taught programming classes for more than 10 years and has been published extensively in leading industry magazines, including Dr. Dobb's and Java Report including many more!
A concise but complete introduction to object-oriented concepts with code examples in Java and UML.
Excellent primer for professional developers moving to object-oriented languages, as well as CS students.
[Lire la suite]
The Object-Oriented Thought Process is a concise and readable primer.
Matt Weisfeld's years of programming, teaching, and writing have given him a flair for presenting highly technical topics in a clear and interesting manner. He is able to blend abstract concepts with ingenious examples and clear illustrations to quickly teach powerful OOP techniques.
The code examples are written in Java and UML but are designed in such a way that a reader with no previous experience will still understand them.
The Object-Oriented Thought Process is a clear and accessible alternative to the often dry and overly dense books available on the market today.
Matt Weisfeld has 18 years of software development and project management experience in COBOL, Pascal, C, C++, Smalltalk, and Java. He has taught programming classes for more than 10 years and has been published extensively in leading industry magazines, including Dr. Dobb's and Java Report including many more!
A concise but complete introduction to object-oriented concepts with code examples in Java and UML.
Excellent primer for professional developers moving to object-oriented languages, as well as CS students.
[Lire la suite]
- Avez-vous lu ce livre ou pensez-vous le lire ?
- Souhaitez-vous ajouter une critique de ce livre sur la page de la rubrique ?
- Avez-vous un commentaire à faire ?
Détails du livre
Sommaire
Critiques (1)
0 commentaire
UML Distilled
A Brief Guide to the Standard Object Modeling Language
de Martin Fowler
Résumé de l'éditeur
- Voulez-vous comprendre les éléments les plus importants des diagrammes de classe ?
- Voulez-vous voir les nouvelles notation d'interaction d'UML2.0 pour ajouter le contrôle des flots aux diagrammes de séquence et la notation non officielle préférée de beaucoup ?
- Voulez-vous connaître les changements entre les différentes versions d'UML ?
- Voulez-vous une référence rapide aux parties les plus utiles de la notation UML ?
- Voulez-vous découvrir quels sont les nouveaux diagrammes ajoutés à UML2.0 sans chercher directement dans la doc officielle ?
Plus de 300 000 développeurs ont bénéficié des précédentes éditions d'UML Distilled. Cette troisième édition est la meilleure ressource pour des aperçus rapides et sensés vers la compréhension et l'utilisation d'UML2.0 et des versions précédentes. Certains lecteurs voudront rapidement se mettre à niveau vers UML2.0 et apprendre l'essentiel d'UML. D'autres utiliseront ce livre comme une référence rapide à portée de main pour les parties les plus classiques d'UML. L'auteur conseille ces deux catégories à l'aide d'uné présentation courte, précise et délimitée.
Ce livre décrit tous les diagrammes UML majeurs, leur utilité et les notations de base pour les créer et les décrypter. Ces diagrammes comprennent les cas d'utilisation, les diagrammes de classe et d’interaction, les collaborations, les diagrammes d'état, d'activité et physiques. Les exemples sont clairs et les explications réduites à la logique de design fondamentale. Si vous êtes comme la plupart des développeurs, vous n'avez pas le temps de connaître les dernières innovations dans le génie logiciel. Cette édition du travail de Martin Fowler vous met au courant de quelques unes des meilleures manières de penser au design logiciel efficace orienté objet en utilisant UML, dans un format agréable qui sera essentiel pour qui veut faire du design logiciel de manière professionnelle.
Édition : Addison-Wesley Professional - 192 pages, 3e édition, 1er septembre 2003
ISBN10 : 0321193687 - ISBN13 : 9780321193681
- Preface.
- Why bother with the UML?
- Structure of the book.
- Changes for the Third Edition.
- Acknowledgements.
- 1. Introduction.
- What Is the UML?
- Ways of Using the UML.
- How We Got to the UML.
- Notations and Meta-Models.
- UML Diagrams.
- What is Legal UML?
- The Meaning of UML.
- UML is not enough.
- Where to Start with the UML.
- Looking for More Information.
- 2. Development Process.
- Iterative and Waterfall Processes.
- Predictive and Adaptive Planning.
- Agile Processes.
- Rational Unified Process.
- Fitting a Process to a Project.
- Fitting the UML into a process.
- Understanding Legacy Code.
- Choosing a Development Process.
- Where to Find Out More.
- 3. Class Diagrams: The Essentials.
- Properties.
- Attributes.
- Associations.
- Multiplicity.
- Programming Interpretation of Properties.
- Bi-directional Associations.
- Operations.
- Generalization.
- Notes and Comments.
- Dependency.
- Constraint Rules.
- When to Use Class Diagrams.
- Where to Find Out More.
- 4. Sequence Diagrams.
- Creating and deleting participants.
- Loops, conditionals and the like.
- Synchronous and Asynchronous Calls.
- When to use Sequence Diagrams.
- 5. Class Diagrams: Advanced Concepts.
- Keywords.
- Responsibilities.
- Static Operations and Attributes.
- Aggregation and Composition.
- Derived Properties.
- Interfaces and Abstract Classes.
- Read Only and Frozen.
- Reference Objects and Value Objects.
- Qualified Associations.
- Classification and Generalization.
- Multiple and Dynamic Classification.
- Association Class.
- Template (Parameterized) Class.
- Enumerations.
- Active Class.
- Visibility.
- Messages.
- 6. Object Diagrams.
- When to use Object Diagrams.
- When to use Object Diagrams.
- 7. Package Diagrams.
- Packages and Dependencies.
- Package Aspects.
- Implementing Packages.
- Where to Find Out More.
- When to Use Package Diagrams.
- 8. Deployment Diagrams.
- When to use deployment diagrams.
- When to use deployment diagrams.
- 9. Use Cases.
- Content of a Use Case.
- Use Case Diagrams.
- Levels of Use Cases.
- Use cases and features (or stories).
- When to Use Use Cases.
- Where to Find Out More.
- 10. State Machine Diagrams.
- Internal Activities.
- Activity States.
- Superstates.
- Concurrent States.
- Implementing State Diagrams.
- When to Use State Diagrams.
- Where to Find Out More.
- 11. Activity Diagrams.
- Decomposing an action.
- Partitions.
- Signals.
- Tokens.
- Flows and Edges.
- Pins and Transformations.
- Expansion Regions.
- Flow Final.
- Join Specifications.
- And there's more.
- When to Use Activity Diagrams.
- Where to Find Out More.
- 12. Communication Diagrams.
- When to use Communication Diagrams.
- When to use Communication Diagrams.
- 13. Composite Structures.
- When to Use Composite Structures.
- When to Use Composite Structures.
- 14. Component Diagrams.
- When to use Component Diagrams.
- When to use Component Diagrams.
- 15. Collaborations.
- When to Use Collaborations.
- When to Use Collaborations.
- 16. Interaction Overview Diagrams.
- When to use Interaction Overview Diagrams.
- When to use Interaction Overview Diagrams.
- 17. Timing Diagrams.
- When to use Timing Diagrams.
- When to use Timing Diagrams.
- Appendix A Changes between UML Versions.
- Revisions to the UML.
- Changes in UML Distilled.
- Changes from UML 1.0 to 1.1.
- Type and Implementation Class.
- Complete and Incomplete Discriminator Constraints.
- Composition.
- Immutability and Frozen.
- Returns on Sequence Diagrams.
- Use of the Term "Role".
- Changes from UML 1.2 (and 1.1) to 1.3 (and 1.5).
- Use Cases.
- Activity Diagrams.
- Changes from UML 1.3 to 1.4.
- Changes from UML 1.4. to 1.5.
- From UML 1.x to UML 2.0.
- Class Diagrams (Basic).
- Interaction Diagrams.
- Class Diagrams (Advanced).
- State Diagrams.
- Activity Diagrams.
Cet ouvrage date déjà dans la courte vie d'UML2, mais il y a tout ce qu'il faut pour comprendre les tenants et les aboutissants de cet outil. Martin Fowler met l'accent sur les diagrammes les plus importants et n'hésite pas à donner son avis sur certains de manière très incisive. Est-ce qu'il ne voit pas à quoi ils pourraient servir ? Sans doute pas, c'est qu'il connaît le domaine très bien et qu'il trouve que ces diagrammes sont inutiles.
Tout le monde devrait lire ce livre, ou du moins l'avoir sous son coude lors des étapes de modélisation. En effet, on trouvera toujours l'outil qu'il nous faut à l'intérieur. Ce dictionnaire es donc indispensable.
Tout le monde devrait lire ce livre, ou du moins l'avoir sous son coude lors des étapes de modélisation. En effet, on trouvera toujours l'outil qu'il nous faut à l'intérieur. Ce dictionnaire es donc indispensable.
Commenter
Signaler un problème
UML Distilled
A Brief Guide to the Standard Object Modeling Language
A Brief Guide to the Standard Object Modeling Language
- Voulez-vous comprendre les éléments les plus importants des diagrammes de classe ?
- Voulez-vous voir les nouvelles notation d'interaction d'UML2.0 pour ajouter le contrôle des flots aux diagrammes de séquence et la notation non officielle préférée de beaucoup ?
- Voulez-vous connaître les changements entre les différentes versions d'UML ?
- Voulez-vous une référence rapide aux parties les plus utiles de la notation UML ?
- Voulez-vous découvrir quels sont les nouveaux diagrammes ajoutés à UML2.0 sans chercher directement dans la doc officielle ?
Plus de 300 000 développeurs ont bénéficié des précédentes éditions d'UML Distilled. Cette troisième édition est la meilleure ressource pour des aperçus rapides et sensés vers la compréhension et l'utilisation d'UML2.0 et des versions précédentes. Certains lecteurs voudront rapidement se mettre à niveau vers UML2.0 et apprendre l'essentiel d'UML. D'autres utiliseront ce livre comme une référence rapide à portée de main pour les parties les plus classiques d'UML. L'auteur conseille ces deux catégories à l'aide d'uné présentation courte, précise et délimitée.
Ce livre décrit tous les diagrammes UML majeurs, leur utilité et les notations de base pour les créer et les décrypter. Ces diagrammes comprennent les cas d'utilisation, les diagrammes de classe et d’interaction, les collaborations, les diagrammes d'état, d'activité et physiques. Les exemples sont clairs et les explications réduites à la logique de design fondamentale. Si vous êtes comme la plupart des développeurs, vous n'avez pas le temps de connaître les dernières innovations dans le génie logiciel. Cette édition du travail de Martin Fowler vous met au courant de quelques unes des meilleures manières de penser au design logiciel efficace orienté objet en utilisant UML, dans un format agréable qui sera essentiel pour qui veut faire du design logiciel de manière professionnelle.
[Lire la suite]
- Avez-vous lu ce livre ou pensez-vous le lire ?
- Souhaitez-vous ajouter une critique de ce livre sur la page de la rubrique ?
- Avez-vous un commentaire à faire ?