1. PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 3:
Software Development Processes

2. Software Development Processes
A methodology includes:
a notation
a process
UML has emerged as a standard notation for OOD
There is much less agreement about process

3. Development modelled as a series of stages
Waterfall Model
Development modelled as a series of stages

4. Waterfall Lifecycle Each stage represents a different activity
Two ‘waterfall’ assumptions
the stages take place in sequence
each activity is completed before the next stage starts
Most versions allow some degree of feedback between stages

5. Risk and the Waterfall Software development is unpredictable
Only testing can validate success of system
The waterfall model postpones testing until the end of the lifecycle
This creates high risk:
we don't find out that the system is failing until the bulk of the development has been carried out

6. Requirements and the waterfall
Requirements always change
complexity of many software systems
systems fit into complex environments
requirement change following installation
flexibility of software makes change seem easy
Waterfall model fixes requirements at start
Inflexible: likely to fail if requirements change

7. Evolutionary Process Models
A response to the inflexibility of the waterfall model
Extensive use of executable prototypes
System evolves toward final form
changes inspired by user feedback on prototypes
Weak for management purposes
no development plan or project milestones

8. Spiral Model
An attempt to formalize the benefits of evolutionary styles without the management shortcomings

9. Characteristics of spiral model
Project iterates through development activities (repeated turns of the spiral)
4 quadrants represent major activities
Each iteration addresses the highest risk for the project
Model does not prescribe a fixed process
detailed sequence of activities can differ depending on nature of project

10. Iterative and Incremental
Responses to waterfall model identify two characteristics of better process models:
Incremental: don't plan to carry out all project in one go, but spread over a number of increments
Iterative: various development activities get carried out repeatedly during development.
Current process models are all iterative and incremental

11. Four Quadrants
The figure shows a spiral development process. Which quadrant of that figure does each of the seven technical activities fit (next slide)?

12. Seven Technical Activities
The figure shows a spiral development process. Which quadrant of previous slide does each of the seven technical activities fit?

13. Relating Quadrants to Activities
The analysis, design, implementation and testing activities all fit into the ‘develop and verify a (partial) solution or product’ segment.
The analysis activity also overlaps the evaluation quadrant where requirements and risks are analyzed.
The testing activity overlaps the ‘review and plan’ quadrant.
The maintenance, project management and quality management activities (including configuration management) operate in all four quadrants.

14. Unified Process (UP) Current state-of-the-art methodology
Initially developed by designers of UML
Structures project as a number of phases
Each phase contains several iterations
Different workflows (activities) are performed in each iteration (notice the traditional set of activities)
The Unified Process takes risk analysis as a central concept. Uses iteration as a means of controlling risk.

15. Unified Process Outline
The balance between workflows is different in different phases

16. UML and the Unified Process
UML is a language
It defines diagrams which represent aspects of software systems
UML’s diagrams can be used in conjunction with many different processes (or even in the absence of a formal process)
Because of their history, there is a close fit between UML and the UP

17. Use cases and the Unified Process
UP is use case driven, meaning:
Systematic use is made of use cases various stages in the design process, realization of use case.
Tests can be systematically derived from use cases to provide acceptance tests for the system.

18. Use cases and the Unified Process
Use cases are a good way to structure requirements, but there are issues not addressed.
Classes that do not interact with the system but are still important.
Component based development, reuse, architectures also need to be considered.
With UCDD the idea is to keep focus on use cases throughout a development, not just in requirements capture. Keeps attention on the requirements.
No single viewpoint (RDD or UCD) suited to all project.

19. Requirements and Analysis (Summary)
UP starts with use cases describing how users interact with the system
A domain model records facts about real world entities
UML use case and class diagrams document these

20. Realization and Refinement (Summary)

21. Realization and refinement (Summary)
Use case realizations indicate how the functionality will be supported by the system
Realizations are documented in UML interaction diagrams
This causes the domain model to be refined into a more implementation-oriented class diagram

22. Specifying behaviour (Summary)
Statecharts specify the behaviour of classes

23. Rational Unified Process
The process can be described in two dimensions:
The horizontal axis represents time and shows the dynamic aspect of the process as it is enacted, and it is expressed in terms of cycles, phases, iterations, and milestones.
The vertical axis represents the static aspect of the process: how it is described in terms of activities, artefacts, workers and workflow. The workflows are similar to the traditional set of activities in the waterfall model.

24. Unified Process Phase 1
Inception--The good idea: specifying the end-product vision and its business case, defining the scope of the project. This phase has several goals:
To describe the initial requirements
To develop and justify the business case for the system
To determine the scope of the system
To identify the people, organizations, and external systems that will interact with the system
To develop an initial risk assessment, schedule, and estimate for the system
To develop an initial tailoring of the Unified Process to meet the exact needs of a particular organization or system.

25. Unified Process Phase 2
Elaboration--Planning the necessary activities and required resources; specifying the features and designing the architecture. Identify significant risks. This phase has several goals:
To produce a proven, architectural baseline for the system
To evolve the requirements model to the "80% completion point"
To develop a coarse-grained project plan for the entire Construction phase
To ensure that the critical tools, processes, standards, and guidelines have been put in place for the Construction phase
To understand and eliminate the high-priority risks of the project needs

26. Unified Process Phase 3
Construction--Building the product and evolving the vision, the architecture, and the plans until the product--the completed vision--is ready for transfer to its users' community. Main iterative spiral is placed here. This phase has several goals:
To describe the remaining requirements
To flesh out the design of the system
To ensure that the system meets the needs of its users and fits into the organization's overall system portfolio
To complete component development and testing, including both the software product and its documentation
To minimize development costs by optimizing resources
To achieve adequate quality as rapidly as possible
To develop useful versions of the system

27. Unified Process Phase 4
Transition--Making the transition from the product to its user's community, which includes: manufacturing, delivering, training, supporting, maintaining the product until the users are satisfied. Final product baseline (also known as a production baseline) of the system. This phase has several goals:
Training materials for the system
Documentation, including user manuals, support documentation, and operations documentation.
The phase is concluded with the Produce Release milestone . To pass this milestone you must show that the users are satisfied with the system and that show that the actual expenditures versus the planned expenditures are still acceptable.

28. The iterative aspects of the workflows in UP.

29. Extreme Programming (XP)
XP is the modern inheritor of the evolutionary style of process model
Key practices:
code review
automated testing
design refactoring (restructuring)
continuous integration

30. Design Flexibility XP stresses need to handle change
Recommends refactoring as development progresses
Assumes existence of technology that makes this feasible and cheap
Round-trip engineering: use of reverse engineering and code generation tools to keep design and code in step

31. Localization
Localization is the process of placing informational items (data and functions) in close physical proximity to each other.
In a modeling context localization requires a mechanism for precisely defining the boundaries of the "area" into which the items are being gathered (e.g. classes, tables or functions).
There needs to be a rationale as to why we group things together. An example of the general idea of localization is concept of cohesion within an module or class.

32. Localization
Different development approaches require different localization schemes:
Functional decomposition approaches localize information around functions (or operations).
Data-driven approaches localize information around data.
Object-oriented approaches localize information around objects (or classes).

33. Localization
The responsibility driven (RDD) approach, described (see later), does not use functional view of the system as a basis for the creation of an object-oriented architecture for that system.
Objects and functions do not map to each other on a one-to-one basis, and the architecture of an object-oriented system is significantly different from the architecture of a functionally decomposed system.
Localization schemes have an effect on software architecture.

34. Localization

35. Localization

36. Conclusions
Software development involves a number of typical activities:
requirements specification
analysis
design
implementation
testing
It is usually not feasible to perform these in strict sequence

37. Current best practice Use case driven Management of risk Flexibility
process driven by user requirements
Management of risk
iterative development phases
incremental delivery of functionality
Flexibility
refactoring
round-trip engineering

38. Responsibility-Driven Design
Responsibility-Driven Design is a set of tools for thinking about systems. It emphasises the concepts of Class, Responsibility and Collaboration. Objects behave by knowing, doing and deciding. Behaviour first. Data second . Class, responsibilities, collaborators are central concepts:
Class A class describes the behaviour of a set of objects of the same kind. Identifies class on card essential when acting out scenarios.

39. Responsibility-Driven Design
Responsibilities are the knowledge that a class maintains and services that it provides. When acting out scenarios analyst must be able to develop or know the current responsibilities of a class. By discussing a problem in terms of responsibilities we increase the level of abstraction. This permits greater independence between objects, a critical factor in solving complex problems. The entire collection of responsibilities associated with an object is often described by the term interface or protocol.

40. Responsibility-Driven Design
Collaborators: A collaborator is a class whose services are needed to fulfil a responsibility. Collaborators must be related to the responsibilities that they help fulfil (1:M). Collaborators may help fulfil responsibilities for several classes. Collaborations only exist to fulfil responsibilities. Collaborations are modelled as one way communications from initiator class to collaborator , the response is a message answer.
The above ideas can be combined using CRC cards.
Using RDD produces a different type of architecture based more on the class diagram than the use case diagram.

41. Architecture and RDD
Using RDD produces a different type of architecture based more on the class diagram than the use case diagram.
RDD can facilitate component based reuse
More of a ‘system view’ rather than a user view.

42. Abstraction
Abstraction
Type
What It Does
Conformance and Justification
Operation
Specifies what an operation achieves in terms of its effect on the object executing it rather than how it works
Does the sequence of statements in code have the specified net effect?
Model
Defines the state of an object (or component) as a smaller and simpler set of attributes than the actual variables or fields used in the design; or simpler than some other model that presents a more detailed view.
How would you compute each abstract attribute from the data stored in the implementation, from the more detailed attributes?
Action
Describes a complex protocol of interaction between objects as a single action, again characterized by the effect it has on the participants.
What sequences of detailed actions will realize the effect of the abstract action? Use state charts, sequence or activity diagrams.
Object
Treats an entire group of objects (such as a component or subsystem or corporation) as if it were a single one, characterizing its behaviour with a type.
How do the constituent objects (and their actions) respond to the abstract object (and its actions)?

43. Unified Process Views (Summary)
The use case view. This contains the basic scenarios that describe the users and the tasks that they need to perform with the aid of a software system. These scenarios are partitioned into use cases. This view validates the logical, process, component and deployment views. Focuses on understandability and usability. The UCV defines the systems external behaviour and is of use to users testers and analysts. It contains the requirements of the system and therefore constrains the other views, which describe the certain aspects of systems design or construction. This view is central to UP a ‘use case driven’ approach. Useful for analysts, users and testers. Serves as the starting point for all subsequent development
Diagrams: Use case diagram. Object, sequence diagrams and collaboration diagrams are created to show how the various design elements interact to produce the desired behaviour.

44. Unified Process Views (Summary)
The logical (or design) view. This is concerned with the functional requirements of the software system, a system focus. Useful for programmers as basis for coding. What should the software do for its intended users?
Diagrams: Typically, this involves the construction of one or more class diagrams. Like the UCV object, sequence diagrams and collaboration diagrams are used. However, here they are used to refine class diagram. Activity diagrams and state charts are also used in the design view.

45. Unified Process Views (Summary)
The implementation view. This is concerned with the organization of the module that comprises a software system. Typically, it addresses the management of source code, data files and executables. A component typically maps to one or more classes, interfaces or collaborations. Useful for configuration management etc
Diagrams: Component diagrams (CD) represent the organization and dependencies among a set of components. A CD is a static implementation view of the system.

46. Unified Process Views (Summary)
The deployment view. This is concerned with the relationship between the various executables (and other run-time components) and their intended computer systems
Diagrams: a deployment diagram is a configuration of run-time processing nodes and their components that live on them. DDs provides a static deployment view. DDs shows how the components are mapped onto processors

47. Unified Process Views (Summary)
The process view. This is concerned with aspects of concurrency, distribution. What are the processes and threads? How do they interact? It deals with such things as response time, deadlock and fault tolerance.
Diagrams: Activity diagrams and statecharts are used in the process view. Statechart diagram are state machine (dynamic process view of the system)
Emphasize event-ordered behavior of an object (useful in modeling reactive systems). They can be used to model behavior of an interface, class, or a collaboration. Activity diagram a bit like statechart with an activity flow (function of a system work flow of control among objects). This provides a dynamic process view of the system.

48. Unified Process Views Summary
These views are related as in the diagram below, the use case view can be seen as central in that it relates the other views. This point could be included in UCV or mentioned separately.

49. How many diagrams? Summary
One diagram type is not adequate to model the diverse aspects of systems.
1) The UML recognises that people have preferences, and that the main purpose of these diagrams is to communicate ideas with colleagues and clients. The UCD has a different audience than the statechart.
2) Different views of a system may more usefully be illustrated by different diagrams.
3) The diagrams individually do not capture the full meaning of the structure of the software, or its behaviour.
4) We are interested in different aspects of a design at different times (e.g. use case for requirements is user focused and statechart for modelling low level state change). More generally we need:
A static model which describes the elements of the system and their relationships to other elements (class diagrams).
A dynamic model which describes the behaviour of a system over a period of time. (e.g. sequence diagrams).

50. Unified Process (UP) requirement document (Summary)
In a project using the Unified Process (UP) for requirement capture the principal components that you would expect in the requirements would be UC diagrams, domain model, textual description, and glossary. The textual description could be similar to the description of the hospital system found in appendix A. It describes the main features of the domain and expected functionality. UP starts with use cases describing how users interact with the system. A domain model records facts about real world entities, the UML use case and class diagrams document these. The domain model is later refined. Systematic use is made of use cases various stages in the design process, realization of use case. The glossary records terms and their definitions for use throughout a project.

51. Realization Refinement (Summary)
Use case realizations indicate how the functionality will be supported by the system
Realizations are documented in UML interaction diagrams.
This causes the domain model to be refined into a more implementation-oriented class diagram. A refinement is detailed description that conforms to another (its abstraction). Everything said about the abstraction holds, perhaps in a somewhat different form, in the refinement. A refinement is relationship between the abstract and detailed descriptions.
Realization similar to refinement but may involve a design, implementation, a change of notation. Statecharts (single object) are use to further specify the behaviour of classes in light of the required behaviour identified in the interaction diagrams (multi-object). These ideas are captured in the diagram below.

52. Realization Refinement (Summary)