Presentation Transcript

1. Trainers: Pierre LE FEVERE DE TEN HOVE Richard WALKER Altran CISObject-Oriented Analysis and Design Session 1 Introduction to OOAD with UML and the UP OOAD Training

2. Objectives and Agenda

   Objectives Profile of the class Overview of OOAD, UML and (R)UP Introduction for 2 certifications OOAD (IBM-Certified Solution Designer) UML (OMG-Certified UML Professional Fundamental: OCUP-F) Agenda Preliminary mock exam The Unified Modeling Language The Unified Process Business process modeling Requirement modeling Architecture Structural modeling Behavioral modeling Design and Technical implementation Training and certification
3. Practice ScopeSoftware Engineering Practice People & Profiles IT Governance Process Improvement IT EXP Technical Experts MGT Project & Service Managers BA Business Analysts QA Quality Assurance Specialists EXEC IT Executive Managers Technical Environments Business Environments Business Solutions IT Infrastructure Best Practices OOAD Training - RWA
4. Object-Oriented Analysis and DesignSoftware EngineeringTraining scope Functional & Technical Expertise for business solutions Objectives Provide end-to-end business solutions From the problem to the implementation Disciplines involved Business Process Re-engineering Organizational change implementation Project Management Global Sourcing Java Platform Audit Worldwide Standards  OOAD Training - RWA
5. UML – Unified Modeling LanguageWhat is it? Unified Modeling Language The UML is a modeling/graphical language for Specifying , Visualizing, Constructing and Documenting …the artifacts of software systems Unified: OMG Standard (www.omg.org) Models are: Abstractions used to better understand complex problems and their potential solutions. Descriptions of a system through specific views showing a particular aspect of the system. UML is not: A method to develop software A project management methodology A set of Object-Oriented best practices A “silver-bullet” solution OOAD Training - RWA
6. UML – Unified Modeling LanguageThe fathers of the language The Three Amigos Grady Booch Booch language and Software Engineering technique Focus on design Class diagrams (responsibilities) and 4-views architecture James Rumbaugh Object Modeling Technique: Object Modelisation Language Focus on analysis Class diagrams (data structure), state machine diagrams Ivar Jacobson Object Oriented Software Engineering: Object Modelisation Language Employ use cases to drive software design Sequence diagrams, communication diagrams (late 60's) OOAD Training - RWA
7. UML – Unified Modeling LanguageHow was it Built? UML 2.1 2007, Availability of the latest version of UML UML 2.0 2004, Adoption of UML 2.0 Superstructure Industrialization UML 1.5 2001, Final Submission to OMG UML 1.4 Standardization UML 1.3 UML 1.1 UML 1.0 Unification (OMG) 1996 UML 0.9 1995 Unified Method 0.8 Booch Method OMT (Rumbaugh) OOSE (Jacobson) Fragmentation OOAD Training - RWA
8. UML – Unified Modeling LanguageWhy is it useful? UML is best suited to Model software intensive systems based on object technology Model business processes Collect specifications Organize documentation Model detailed design Prepare tests scripting Develop Implementation structure Communicate ideas about software design UML allows specifying systems with an implementation-independent approach UML is easy to understand for developers but also provides advanced features for expert analysts, designers and architects OOAD Training - RWA
9. UML – Unified Modeling LanguageHow to use it? UML Case tools Visual Paradigm: VP-UML (free community version) http://www.visual-paradigm.com/ Gentleware: Apollo and Poseidon http://gentleware.com Magicdraw http://www.magicdraw.com/ Select Business Solution: Component Architect http://www.selectbs.com/ IBM: Rational Software Modeller http://www-306.ibm.com/software/awdtools/modeler/swmodeler/index.html Enterprise architect Visual studio Eclipse (with plug-in) OOAD Training - RWA
10. UML – Unified Modeling LanguageConclusion UML = language to understand and being understood UML = tool  This is not enough ! Unified Language but no unified Methodology Structured Programming Waterfall and V-Schemas Agile approaches Unified Process X-Treme Programming Scrum Feature Driven Development … OOAD Training - RWA
11. UP – Unified ProcessSoftware Development Approaches Structured Programming (~ 70’s) Top-down approach Program structure  subsections  modules  functions Encourage reuse Focused on processes rather than on data Modular design (<> changes) Waterfall and V-Schemas Simple sequential software development method Each phase is ordered and performed totally and validated Closed to changes (limited come-back in phases) Profile reallocation across projects Difficult planning and budget estimates Testing and user feedback at the end Agile Unified Process X-Treme programming … OOAD Training - RWA
12. UP – Unified Process What is a process? Process Defines Who is doing What, When, Where to do it, and How to reach a certain goal. New or changed New or changed Requirements System Software Engineering Process OOAD Training - RWA
13. UP – Unified Process Introduction Software Engineering Process Assigning tasks & responsibilities Ensuring high-quality within schedule & budget Focused on content UP axioms Iterative & Incremental Requirements (Use case) & Risk driven Focused on architecture (strategy more important that tactics) <> project management methodology OOAD Training - RWA
14. UP – Unified Process Rational Unified Process OOAD Training - RWA
15. In RUP all disciplines are expressed in terms of roles, activities and artifacts A unit of work with a clear purpose that a worker will perform Activity = element of planning & progress The behaviour and responsibilities of a (group of) individual(s). An individual can have many hats Worker = role A piece of information produced, modified or used by a process Artifact = Input & Output of activities Unified ProcessRational Unified Process Static aspect OOAD Training - RWA
16. RUP - Rational Unified Process Dynamic aspect A project is broken into 4 phases Each phase can have several iterations You may have iterations without increments  iteration failed to provide added value You may have increments without iterations  waterfall approach Major Milestones Inception Elaboration Construction Transition time OOAD Training - RWA

17. Objectives and Agenda

    Objectives Profile of the class Overview of OOAD, UML and (R)UP Introduction for 2 certifications Agenda Preliminary mock exam The Unified Modeling Language The Unified Process Business process modeling Requirement modeling Architecture Structural modeling Behavioral modeling Design and Technical implementation Training and certification
18. Business process modelingWhat is a business process? A business process Isacollectionoforderedworkactivities Aims to reach a Goal Has specific inputs and outputs Uses resources Creates value for the customer (internal or external) OOAD Training
19. Business Process Modeling Activity DiagramsIntroductiveexample OOAD Training
20. Business process modelingIntroduction to BPM Objectives Understand the business Identify how the future application fits into the organization Establish a communication channel Software engineering <-----------> business engineering Identify areas of improvement Current issues and potential improvements Delimit projects scope Identify how the efforts will fit the overall business Decrease change requests risks Focusing on business processes and needs insures good understanding of business before jumping straight to system requirements Start with Business Process Modeling? involve a lot of or complex processes or workflows Involve unclear or to-be-improved processes involve many departments and users. OOAD Training
21. Requirement ModelingOnline Banking System OOAD Training
22. WHY? WHO? WHEN? WHAT? WHERE? HOW? Requirement ModelingUse case Definition Use case is A use case is the description of a functionality of a system from the user point of view A use case describes a functional requirement in terms of interaction between a user and the system A use case must provide a business benefit to the user Identification OOAD Training
23. Requirement ModelingArtifacts A use case diagram is a model that emphases: the interaction between the actors and the systems through the use cases the relations between uses cases the relation between actors Each use case must be textual Inception phase: High level use cases 10 – 20% detailed Elaboration phase 100% detailed OOAD Training
24. Architecture Architecture is many things to many different interested parties multiple project’s stakeholders with their own concerns and view of the system to be developed Architecture embodies, for each stakeholder, views of the system that addresses their concerns, models the choices/decisions, and suppresses the other details. Not all systems require all the same number of views OOAD Training
25. End-user Functionality Software Architecture RUP presents the Software Architecture in the 4+1 views LogicalView Implementation View Analysts/Designers Functionality Programmers Software management Use-Case View Process View Deployment View System integrators System engineers Performance Scalability Synchronisation and concurrency System topology Delivery, installation Communication OOAD Training
26. FAR Core ArchitectureLogical View OOAD Training
27. FAR Core ArchitectureProcess View OOAD Training
28. FAR Core ArchitectureDeployment View OOAD Training
29. FAR Core ArchitectureImplementation View OOAD Training

30. Objectives and Agenda

    Objectives Profile of the class Overview of OOAD, UML and (R)UP Introduction for 2 certifications Agenda Preliminary mock exam The Unified Modeling Language The Unified Process Business process modeling Requirement modeling Architecture Structural modeling Behavioral modeling Design and Technical implementation Training and certification
31. Structural modeling The structural diagrams help us to represents the structural aspects of a software. Those structural aspects may be Sets of objects description with their interrelationships Physical components with their relationships Material configuration of a system Here are the main structural UML diagrams Class Diagrams Package Diagrams Component Diagrams Deployment Diagrams OOAD Training
32. Class DiagramHealthcare insurance illustration OOAD Training
33. Structural modelingClass Diagrams What is a class diagram? A class diagram is a view of a system that emphasizes the structure of the classes. A class diagram shows the static structure of the model the entities that exist (classes, interfaces) internal structure (properties, methods) relationships to other entities Class diagrams are one of the most common type of UML diagram. Why use class diagrams? For conceptual/domain modeling For detailed design modeling Use in UP: Inception phase: Domain model (Conceptual model) Elaboration phase: Analysis model (Specification model) Construction phase: Design model (Implementation model) OOAD Training
34. Class DiagramsHow to identify? Identify Objects and their Relationships: from Users (definitions of business objects) from Use Cases (names of used concepts are potentially objects names) Identify Business Classes, their Relationships and their classification: A class is an abstract representation of a set of objects that share the same structure, behavior and relationships All objects described by a class share the same definition Attributes Operations Relations Remove Business Classes that: Are redundant Are too general or specific Represent an attribute or a behavior OOAD Training
35. Class DiagramHow to refine? Identify Design classes Start thinking implementation from Business Concept from IT Concept (persistence) Refine Classes Define attributes Association Time to think about: Abstraction: Favor some details over others to minimize complexity Encapsulation: Hide information to reduce coupling and manage complexity. OOAD Training
36. Behavioral modeling The behavioral diagrams help us to define the processes that will support the system. The behavioral aspects may be: Roles and their interactions with the system The behavior and communications of objects over time The life cycle of objects in the system (~> events) Control aspects of a system Algorithm of operations Here are the main behavioral UML diagrams Use case diagrams Sequence Diagrams Collaboration Diagrams (aka Communication D.) State Transition Diagrams Activity Diagrams OOAD Training - RWA
37. Activity diagrams Processing an order OOAD Training - RWA
38. Behavioral modelingActivity Diagrams What is an activity diagram? An activity diagram is a view of a system that emphasizes the flow of control of the target system (e.g. complex business rules) focuses on internal treatment An activity diagram shows the dynamic structure of the model activity (operation invocation or business process step) decision points parallel activities (fork, join) guard conditions Why use activity diagrams? Define a logical way for a work process Simple way to describe workflows and the algorithm of an operation Easy to understand by users <-> it can be a support for requirements discussions Very useful to detail a Use Case Assign responsibilities OOAD Training - RWA
39. State Machine Diagrams The Phone OOAD Training - RWA
40. Behavioral modelingState Machine Diagrams What is a state machine diagram? A state machine diagram is a view of a system that captures the life-cycle of objects or sub-systems emphasizes the various states that an object may be in and the transitions between them (through internal and external events) defines how will behave an entity to various events depending on its preceding states (and not only its inputs). A state machine diagram shows the dynamic structure of the model states (initial, final and regular) transitions (unstoppable) actions (uninterruptible) historical pseudo-state Why use state machine diagrams? Simple way to describe the life-cycle of complex objects OOAD Training
41. Sequence Diagrams Withdraw Money from ATM Draws attention to time sequence OOAD Training - RWA
42. Communication Diagrams Make a Phone Call Draws attention to object relationships OOAD Training - RWA
43. Behavioral ModelingInteraction Diagrams What is an interaction diagram ? An interaction diagram is view of a system that describes how objects behave, interact and communicate with each others shows a single path of execution (scenario) An interaction diagram shows the dynamic structure of the model objects messages (synchronous, asynchronous) Conditions (continuity, time, etc.) There are two types of interaction diagrams Sequence diagrams Communication diagrams Why use interaction diagrams? Define how objects collaborate or interact in a certain situation Introduce time in modelling Very close to implementation OOAD Training - RWA
44. UML 2.0Diagrams Taxonomy UML2 Superstructure OOAD Training – RWA
45. Class Diagrams Use Case Diagrams Static Diagrams Object Diagrams Dynamic diagrams Sequence Diagrams Collaboration Diagrams Component Diagrams Deployment Diagrams Statechart Diagrams Activity Diagrams Back to UML 1.4 Dynamics / behavior diagrams Object lifecycle Goal-driven collaboration between objects Static diagrams Object Types Object Relationships Models OOAD Training - RWA
46. Class Diagrams Use Case Diagrams Structural Diagrams Object Diagrams Package Diagrams Behavioral diagrams Sequence Diagrams Communication Diagrams Component Diagrams Deployment Diagrams State Machine Diagrams Timing Diagrams Composite Structure Diagrams Interaction Overview Diagrams Activity Diagrams UML 2.0 Behavioral diagrams Interelated processes Objects interactions and states Structural diagrams System Components Components relations and dependencies Models OOAD Training - RWA
47. UML 2.0What’s new? Model Driven Architecture Higher level of abstractions for defining Platform Independent Models Iterative refinements for specifying Platform Specific Models dependent on technological choices Code skeleton generation thanks to PSMs New Diagrams Package diagrams: to model the packages hierarchy and dependencies Composite structure diagrams: to model the internal structure and internal collaboration of complex components at run-time including interaction points to other parts of the system Interaction overview diagrams: to model complex methods with an extended activity diagrams whose nodes are interaction diagrams Timing diagrams: to model the behaviour of one or more objects during a period of time, display the change in state and time/duration constraints Communication diagrams: new name for collaboration diagrams. OOAD Training – RWA

48. Objectives and Agenda

    Objectives Profile of the class Overview of OOAD, UML and (R)UP Introduction for 2 certifications Agenda Preliminary mock exam The Unified Modeling Language The Unified Process Business process modeling Requirement modeling Architecture Structural modeling Behavioral modeling Design and Technical implementation Training and certification
49. Design & Technical Implementations Time to think about Reuse In analysis  Data In implementation  Services Patterns Analysis Patterns Architectural Patterns Design Patterns Implementation techniques Pair programming Testing phases OOAD Training
50. Design & Technical ImplementationsWhat is Reuse? Many Object-Oriented design best practices increase reuse Design by contract Open-closed principle Coupling and cohesion … Some methods must be generalized in order not to write them at each time their usage is needed Patterns and Design Patterns are part of reuse techniques OOAD Training
51. Design & Technical ImplementationsWhat are (design) Patterns? Patterns An abstraction from a concrete form which keeps recurring in specific, non-arbitrary contexts [generic definition] A recurring solution to a common problem in a given context and system of forces [Alexander] A successfully recurring "best practice" that has proven itself in the "trenches" A literary format for capturing the wisdom and experience of expert designers, and communicating it to novices Design Patterns “Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context” “These patterns solve specific design problems, make object-oriented designs more flexible, elegant and ultimately reusable, basing new designs on prior experience, without having to rediscover them“ OOAD Training
52. Design & Technical ImplementationsGoF Design Patterns Structural Design Patterns (Way to assemble objects) Creational Design Patterns (Object creation process) Behavioral Design Patterns (Cooperation between objects) OOAD Training
53. Design PatternsFaçade Façade Design Pattern Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use. OOAD Training
54. Analysis Patterns An abstract, conceptual template Intended for instantiation in an analysis model through binding as with any pattern Later refined through design Relevant to only one domain, or span many domains Example: Effectivity Advantage: simple & easy to understand Disadvantage: client needs to be aware of the temporal aspect OOAD Training 54
55. Design & Technical Implementations:What are Implementation / Pair Programming? Implementation Either with both hands, eventually from templates Either with tools (Rational / Together J…) Pair Programming One person types and thinks tactically about the method being created, while the other thinks strategically about how that method fits into the class Partners are equal no tutoring Pairing is dynamic partners continuously swap roles (e.g., when coder gets stuck) no partnership is permanent (e.g., partners change once a day) Ensured quality (on-the-fly review) and communication Used in XP OOAD Training
56. Design & Technical Implementations:What is Testing? Unit Testing Make sure all tests are fully automatic and that they check there own results A suite of tests is a powerful bug detector that decapitates the time it takes to find bugs Run your tests frequently. Every test at least everyday When you get a bug report, start by writing a unit test that exposes the bug It is better to write and run incomplete tests than not to run tests Integration Testing To ensure that all parts developed separately fit together Interfaces System Testing The system as a whole Features Developer focused Acceptance Testing The system as a whole also Requirements Customer focused Non-regression Testing Before migration to operation, verify that previously delivered software still works OOAD Training

57. Objectives and Agenda

    Objectives Profile of the class Overview of OOAD, UML and (R)UP Introduction for 2 certifications Agenda Preliminary mock exam The Unified Modeling Language The Unified Process Business process modeling Requirement modeling Architecture Structural modeling Behavioral modeling Design and Technical implementation Training and certification
58. Training and certificationQ&A Certifications IBM Certified Solution Designer – Object Oriented Analysis and Design, with UML 2 IBM Test 833: Object-Oriented Analysis and Design - Part 1 (Analysis) IBM Test 834: Object-Oriented Analysis and Design - Part 2 (Design) OMG Certified for UML OCUP Fundamental OCUP Intermediate OCUP Advanced Course 1 introduction course (with short mock exam) 4 sessions of 4 hours 1 long mock exam Personal home work (~2h/session) OOAD Training - PLF
59. Training and certification Calendar 05/11 - Session 1 - Introduction 12/11 - Session 2 - SwE Processes 19/11 - Session 3 - Inception 26/11 - Session 4 - Elaboration 1st iteration 03/11 - Session 5 - Elaboration 2nd iteration 10/12 - Session 6 - Mock exam + Q&A Take IBM-833 exam before 31/01/2010 OOAD Training - PLF

60. 1 link

    http://ooad.wikispaces.com/ Forums Wiki Material News Agenda Use full name when choosing login!!