Chapter 6 View Alignment Techniques and Method Customization (Part I)

1. Chapter 6View Alignment Techniques and Method Customization(Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence S.W. Lau and Y.K. Leung McGraw-Hill Education (Asia), 2005 Dr. Hussein Al-Zoubi

2. Objectives • After you have read this chapter, you should be able to • Appreciate the benefits of using a method for software development. • Understand the limitations of current software development methods. • Understand the framework of View Alignment Techniques. • Apply the View Alignment Techniques to customize and create a method. • Use the Activity Analysis Approach effectively for developing workflow-oriented and activity intensive software systems.

3. What Is Software Development Method? • A software development method consists of a complete set of activities needed to transform users’ requirements into a consistent set of artifacts that represent a software product. • Typically, a software development method specifies a series of stages that encompass requirements gathering, design, development, testing, delivery, maintenance and enhancement of a system, and helps the developer build software systems in a reliable and consistent way. • In general, software development methods allow the building of models from model elements that constitute the fundamental concepts for representing systems or phenomena.

4. Components of Software Development Methods (cont’d) • Representation. A set of recommended representation (notation), e.g., the Unified Modeling Language (UML)) consisting of one or more forms of a notation that can be used to model both the structure of the initial problem (requirements) and the intended solution, using one or more viewpoints (models) and different levels of abstraction. • Process. It provides a framework from which a comprehensive plan for software development should be established. This development plan consists of a specific ordered set of tasks aimed at producing software solutions, e.g. Unified Process.

5. Components of Software Development Methods (cont’d) • Techniques. They are heuristics, guidelines and procedures that help designers develop the software development plan for their project. In other words, they help customize the process framework for the system being developed, such as defining the order of tasks to be carried out within the process, selecting the models and their perspective to be focused at the optimum level of abstraction.

6. Components of Software Development Methods • A software development method primarily comprises three components: • a process, • a representation system or a modeling notation, and • techniques, heuristics, steps or procedures

7. Why Traditional Software Methods Didn’t Work Miracles? • There is no universal method that can be readily applied to all problems in any circumstances without the need for customization. • Demarco points out that to ensure success the project team should tailor the method to needs of the individual project rather than attempt force-fitting the project into the Methodology. • Spolsky’s story

8. Hurdles in Applying the Object-oriented Approach • The UML provides an extremely rich set of notations for representing systems. Booch suggests that 80% of software projects use only about 20% of the UML notation. • To the designer, it would be rather difficult to decide which subset of UML notation should be used for the project at hand.

9. Hurdles in Applying the Object- oriented Approach (cont’d)

10. Hurdles in Applying the Object- oriented Approach (cont’d) • Designers are often confronted with many questions throughout the development life cycle, and the following are some typical ones: • What models are required to represent the system? • How do I apply the selected models to perform the development work? • Which model should I use first, and which model(s) should follow next? • How can I ensure that the models of the system are consistent?

11. Current Object-oriented Development Approaches • The Unified Modeling Language is now the defacto standard graphical language for representing systems in the software industry. • The Unified Process is a widely used software development process. In the Unified Process, a system is built incrementally through a number of iterations in which the designer may perform requirements capturing, analysis, design, implementation and testing tasks.

12. Unified Process • The iterations are divided into four phases: inception, elaboration, construction and transition

13. Unified Process (cont’d) • Each phase has a different focus: • Inception Phase. This phase focuses on establishing the business case, defining the scope of the system and estimating the amount of resources including time required to complete the project. • Elaboration Phase. In this phase, the core architecture of the system is developed incrementally. Risks are resolved according to priorities, and the scope of the system is refined. • Construction Phase. In this phase, low risk elements of the system are implemented and tested incrementally. The system is prepared for deployment. • Transition Phase. Beta release of the system is deployed to the end users. Bug fixes and other tasks such as refining the system are performed.

14. Unified Process (cont’d) • The work activities of the Unified Process in the same subject area are categorized as a workflow (some authors call it a discipline).

15. Techniques • As mentioned earlier, the techniques part is the most difficult component of the entire software development method. • Jacobson considers that teamwork should be the thing that glues the representation and process components together but offers very little details on how we can customize or create a method to solve our problem. • Nonetheless, he does provide some hints on which model(s) should be used in each workflow. • Each of these models associated with a workflow is elaborated by a sub-figure indicating the types of diagrams likely to be used.

16. Techniques (cont’d)

17. Techniques (cont’d)

18. Techniques (cont’d)

19. Techniques (cont’d)

20. Techniques (cont’d) • Despite these hints, little clue is provided on the selection of the right model (UML diagram) to start with and the order in which these models (UML diagrams) should be developed. • Still don’t know how to develop the required UML models.

21. Traceability and Models Consistency • Another frequently asked question in developing models is “how do we ensure the models we have created are consistent?” • <<trace>> is one of the often used stereotypes in Rambaugh, Booch and Jacobson’s publication entitled The Unified Software Development Process. • Jacobson emphasizes many times in this book on the traceability between a model and its subsequent realization models, but there is little hint as to how we can actually ensure traceability among the models.

22. Traceability and Models Consistency (cont’d)

23. Need for Method Customization • There is no universally applicable design method. • There are many different factors that would affect our design decisions: • the competence and skill levels and the prior experience of the software development team • different application domains also require different focuses or impose special constraints • lifecycle factors: time to market, expected life span, planned future releases • technological factors: programming languages, development tools, databases, middleware, communication, distribution, etc.