OBJECT-ORIENTED ANALYSIS AND DESIGN

1. OBJECT-ORIENTED ANALYSIS AND DESIGN lecture 1-6,Chitkara University

2. Stages in a Software Project • Requirements Writing Understanding the Client’s environment and needs. • Analysis Identifying the concepts (classes) in the problem domain and their static associations • Design Identifying “solution domain” classes and mapping the functionality into these classes • Implementation Constructing and individually testing the classes that compose the system. • System Integration and Testing Testing the system as a whole and doing corrective maintenance • Maintenance Adapting the system to a changing environment to extend its useful life lecture 1-6,Chitkara University

3. The Waterfall Lifecycle Approach Thoroughly clarify, record, or implement each phase of the project before beginning the next. The subsequent phase is based upon the design documentation previously developed. Requirements Analysis Design Implementation Integration and Testing Maintenance lecture 1-6,Chitkara University

4. The Waterfall Lifecycle Approach Problems with the Waterfall Approach Large steps are taken in which many decisions are made without the benefit of feedback. Requirements and Design decisions, once established, are frozen in place. Speculative decisions increase and compound. High risk or difficult problems are tackled late. There is low adaptability for incorporating either design or implementation concepts “learned” in the development process into the project. lecture 1-6,Chitkara University

5. The Unified Process The Unified Process is a software development process or methodology that above all promotes Iterative Development. The result of each iteration is an executable, but incomplete system. The system may need many iterations before it is ready for production. Benefits of iterative development include: • Early mitigation of high risks • Early visible progress. • Early feedback, user engagement, and adaptation, leading to a system that more nearly meets the needs of the various stakeholders. • Managed complexity – no compounding of complexity by postponing the implementation phase. • Learning within an iteration. lecture 1-6,Chitkara University

6. The Unified Process(The Rational Unified Process (RUP), adopted by IBM for system development) • Supports System Development Using the Unified Model Language (UML) • Evolutionary process where the system is built iteratively and incrementally in several builds starting from the requirements phase • Architecture-centric lecture 1-6,Chitkara University

7. What is Rational Unified Process (RUP)? • RUP is a complete software-development process framework , developed by Rational Corporation. • It’s an iterative development methodology based upon six industry-proven best practices. • Processes derived from RUP vary from lightweight—addressing the needs of small projects —to more comprehensive processes addressing the needs of large, possibly distributed project teams. lecture 1-6,Chitkara University

8. Phases in RUP • RUP is divided into four phases, named: • Inception • Elaboration        • Construction • Transition lecture 1-6,Chitkara University

9. iteration Release Final release The Unified Process phase phase Inc. Elaboration Construction Trans. The end of each iteration is a minor release lecture 1-6,Chitkara University

10. The Unified Process Inception: Define the scope of the system (identify all external entities with which the system will interact and define the nature of the interactions) Elaboration:Specify features and develop the architecture Construction:Build the system Transition:Transition Product to its users lecture 1-6,Chitkara University

11. lecture 1-6,Chitkara University

12. Inception • The life-cycle objectives of the project are stated, so that the needs of every stakeholder are considered. Scope and boundary conditions, acceptance criteria and some requirements are established. lecture 1-6,Chitkara University

13. Inception - Activities • Formulate the scope of the project. • Needs of every stakeholder, scope, boundary conditions and acceptance criteria established. • Plan and prepare the business case. • Define risk mitigation strategy, develop an initial project plan and identify known cost, schedule, and profitability trade-offs. • Synthesize candidate architecture. • Candidate architecture is picked from various potential architectures • Prepare the project environment. lecture 1-6,Chitkara University

14. Inception - Exit criteria • An initial business case containing at least a clear formulation of the product vision - the core requirements - in terms of functionality, scope, performance, capacity, technology base. • Success criteria (example: revenue projection). • An initial risk assessment. • An estimate of the resources required to complete the elaboration phase. lecture 1-6,Chitkara University

15. Elaboration • An analysis is done to determine the risks, stability of vision of what the product is to become, stability of architecture and expenditure of resources. lecture 1-6,Chitkara University

16. Elaboration - Entry criteria • The products and artifacts described in the exit criteria of the previous phase. • The plan approved by the project management, and funding authority, and the resources required for the elaboration phase have been allocated. lecture 1-6,Chitkara University

17. Elaboration - Activities • Define the architecture. • Project plan is defined. The process, infrastructure and development environment are described. • Validate the architecture. • Baseline the architecture. • To provide a stable basis for the bulk of the design and implementation effort in the construction phase. lecture 1-6,Chitkara University

18. Elaboration - Exit criteria • A detailed software development plan, with an updated risk assessment, a management plan, a staffing plan, a phase plan showing the number and contents of the iteration , an iteration plan, and a test plan • The development environment and other tools • A baseline vision, in the form of a set of evaluation criteria for the final product • A domain analysis model, sufficient to be able to call the corresponding architecture ‘complete’. • An executable architecture baseline. lecture 1-6,Chitkara University

19. Construction • The Construction phase is a manufacturing process. It emphasizes managing resources and controlling operations to optimize costs, schedules and quality. This phase is broken into several iterations. lecture 1-6,Chitkara University

20. Construction - Entry criteria • The product and artifacts of the previous iteration. The iteration plan must state the iteration specific goals • Risks being mitigated during this iteration. • Defects being fixed during the iteration. lecture 1-6,Chitkara University

21. Construction - Activities • Develop and test components. • Components required satisfying the use cases, scenarios, and other functionality for the iteration are built. Unit and integration tests are done on Components. • Manage resources and control process. • Assess the iteration • Satisfaction of the goal of iteration is determined. lecture 1-6,Chitkara University

22. Construction - Exit Criteria • The same products and artifacts, updated, plus: • A release description document, which captures the results of an iteration • Test cases and results of the tests conducted on the products, • An iteration plan, detailing the next iteration • Objective measurable evaluation criteria for assessing the results of the next iteration(s). lecture 1-6,Chitkara University

23. Transition • The transition phase is the phase where the product is put in the hands of its end users. It involves issues of marketing, packaging, installing, configuring, supporting the user-community, making corrections, etc. lecture 1-6,Chitkara University

24. Transition - Entry criteria • The product and artifacts of the previous iteration, and in particular a software product sufficiently mature to be put into the hands of its users. lecture 1-6,Chitkara University

25. Advantages of RUP • The RUP puts an emphasis on addressing very early high risks areas. • It does not assume a fixed set of firm requirements at the inception of the project, but allows to refine the requirements as the project evolves. • It does not put either a strong focus on documents • The main focus remains the software product itself, and its quality. lecture 1-6,Chitkara University

26. Drawbacks of RUP • RUP is not considered particularly “agile” However, recent studies have shown that by adopting the right essential artifacts RUP is agile. • It fails to provide any clear implementation guidelines. • RUP leaves the tailoring to the user entirely. lecture 1-6,Chitkara University

27. Management of a Software Project There are two groups involved with the management of a software project: “Management” – whose concern is resource allocation, delivery dates, profit margin, etc. Management likes “benchmarks” exemplified in the Waterfall approach. Due dates can be set, and resources allocated to each phase of the project, and project management documents can be completed according to a schedule. Technical staff – whose concern is producing a well-engineered product within the constraints of the project. The iterative process as emphasized in UP is a better approach for engineering a software product, but it less suited for producing project reports that indicate the status of the project and the completion of well-defined phases of the work important to management. lecture 1-6,Chitkara University

28. Timeboxing Management of a UP project. Iterations are “timeboxed” or fixed in length. Iteration lengths of between two to six weeks are recommended. Each iteration period has its own development plan. If all the planned activities cannot be completed during an iteration cycle, the completion date should not be extended, but rather tasks or requirements from the iteration should be removed and added to the next iteration cycle. lecture 1-6,Chitkara University

29. What is Object Oriented Analysis? • The emphasis is on finding and describing the objects (or concepts) in the problem domain. • In a Library Information System, some of the concepts include Book, Library, and Patron. lecture 1-6,Chitkara University

30. Obj s: Obj y: Class A Class B 3: Set_Alarm(message) Object Oriented AnalysisOOA • OOA Develops a Logical Model of the system as a set of interacting domain objects • The model consists of two views • The static view: defines the classes • and their dependencies • The dynamic view: models the scenarios of • interactions between objects Requires Service From Class B Class A Class B lecture 1-6,Chitkara University

31. What is Object Oriented Design? • The emphasis is defining software objects and how they collaborate to fulfill the requirements. • In a Library Information System, a Book software object may have a title attribute and a get Chapter method. lecture 1-6,Chitkara University

32. Implementation • During Implementation, or Object-Oriented Programming, design objects are implemented, such as a book class in Java. • Implementation is also known as Coding or Construction. lecture 1-6,Chitkara University

33. The Unified Modeling Language UML • UML stands for Unified Modeling Language • The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system • It can be used with all processes, throughout the development life cycle, and across different implementation technologies. lecture 1-6,Chitkara University

34. UML Concepts The UML may be used to: • Develop a Requirements Model • Use Case diagrams - Define the scope, and display the boundary of a system & its major functions using use cases and actors • System Sequence diagrams - Illustrate use case realizations or scenarios of interactions between the actors and the system • Develop the Analysis model • Class diagrams - Represent a static structure of a system • State Charts - Model the behavior of objects lecture 1-6,Chitkara University

35. UML Concepts • Develop the architecture design model • Class diagrams: Represent the static architecture using packages or subsystems • Design Sequence diagrams: Represent the dynamic interactions between the design objects • Develop the physical architecture implementation model 1. component & deployment diagrams: Reveal the physical implementation architecture lecture 1-6,Chitkara University

36. SCENARIOS ACTORS USE CASES UML Development - Overview REQUIREMENTS ELICITATION Time D Requirements Engineering System/Object SEQUENCE DIAGRAMS A T A ANALYSIS CLASS DIAGRAM(S) StateChart DIAGRAMs ANALYSIS Specify Domain Objects D I OPERATIONCONTRACTS C T Architectural Design Include Design Objects I SUBSYSTEM CLASS/ OR COMPONENT DIAGRAMS DESIGNSEQUENCE DIAG. DEPLOYMENTDIAGRAM O N DESIGN DIAGRAMS A R Detailed DESIGN Y Object Design IMPLEMENTATION CHOICES IMPLEMENTATION ActivityDIAGRAMS IMPLEMENTATION PROGRAM lecture 1-6,Chitkara University

37. UML Diagrams Structural diagrams – Used to describe the building blocks of the system – features that do not change with time. These diagrams answer the question – What's there? Behavioral diagrams – Used to show how the system evolves over time (responds to requests, events, etc.) lecture 1-6,Chitkara University

38. UML Diagrams lecture 1-6,Chitkara University

39. UML Diagrams lecture 1-6,Chitkara University