The UML is typically used as a part of a software development process, with the support of a suitable CASE tool, to define the requirements, the interactions and the elements of the proposed software system. The exact nature of the process depends on the development methodology used. An example process might look something like the following:
1. Capture a Business Process Model. This will be used to define the high level business activities and processes that occur in an organization and to provide a foundation for the Use Case model. The Business Process Model will typically capture more than a software system will implement (ie. it includes manual and other processes).
2. Map a Use Case Model to the Business Process Model to define exactly what functionality you are intending to provide from the business user perspective. As each Use Case is added, create a traceable link from the appropriate business processes to the Use Case (ie. a realisation connection). This mapping clearly states what functionality the new system will provide to meet the business requirements outlined in the process model. It also ensures no Use Cases exist without a purpose.
3. Refine the Use Cases - include requirements, constraints, complexity rating, notes and scenarios. This information unambiguously describes what the Use Case does, how it is executed and the constraints on its execution. Make sure the Use Case still meets the business process requirements. Include the definition of system tests for each use case to define the aceptance criteria for each use case. Also include some user acceptance test scripts to define how the user will test this functionality and what the acceptance criteria are.
4. From the inputs and outputs of the Business Process Model and the details of the use cases, begin to construct a domain model (high level business objects), sequence diagrams, collaboration diagrams and user interface models. These describe the 'things' in the new system, the way those things interact and the interface a user will use to execute use case scenarios.
5. From the domain model, the user interface model and the scenario diagrams create the Class Model. This is a precise specification of the objects in the system, their data or attributes and their behavior or operations. Domain objects may be abstracted into class hierarchies using inheritance. Scenario diagram messages will typically map to class operations. If an existing framework or design pattern is to be used, it may be possible to import existing model elements for use in the new system. For each class define unit tests and integration tests to thoroughly test i) that the class functions as specified internally and that ii) the class interacts with other related classes and components as expected.
6. As the Class Model develops it may be broken into discrete packages and components. A component represents a deployable chunk of software that collects the behaviour and data of one or more classes and exposes a strict interface to other consumers of its services. So from the Class Model a Component Model is built to define the logical packaging of classes. For each component define integration tests to confirm that the component's interface meets the specifcation given it in relation to other software elements.
7. Concurrent with the work you have already done, additional requirements should have been captured and documented. For example - Non Functional requirements, Performance requirements, Security requirements, responsibilities, release plans & etc. Collect these within the model and keep up to date as the model matures.
8. The Deployment model defines the physical architecture of the system. This work can be begun early to capture the physical deployment characteristics - what hardware, operating systems, network capabilities, interfaces and support software will make up the new system, where it will be deployed and what parameters apply to disaster recovery, reliability, back-ups and support. As the model develops the physical architecture will be updated to reflect the actual system being proposed.
9. Build the system: Take discrete pieces of the model and assign to one or more developers. In a Use Case driven build this will mean assigning a Use Case to the development team, having them build the screens, business objects, database tables, and related components necessary to execute that Use Case. As each Use Case is built it should be accompanied by completed unit, integration and system tests. A Component driven build may see discrete software components assigned to development teams for construction.
10. Track defects that emerge in the testing phases against the related model elements - eg. System test defects against Use Cases, Unit Test defects against classes & etc. Track any changes against the related model elements to manage 'scope creep'.
11. Update and refine the model as work proceeds - always assessing the impact of changes and model refinements on later work. Use an iterative approach to work through the design in discrete chunks, always assessing the current build, the forward requirements and any discoveries that come to light during development.
12.Deliver the complete and tested software into a test then production environment. If a phased delivery is being undertaken, then this migration of built software from test to production may occur several times over the life of the project.
1. Capture a Business Process Model. This will be used to define the high level business activities and processes that occur in an organization and to provide a foundation for the Use Case model. The Business Process Model will typically capture more than a software system will implement (ie. it includes manual and other processes).
2. Map a Use Case Model to the Business Process Model to define exactly what functionality you are intending to provide from the business user perspective. As each Use Case is added, create a traceable link from the appropriate business processes to the Use Case (ie. a realisation connection). This mapping clearly states what functionality the new system will provide to meet the business requirements outlined in the process model. It also ensures no Use Cases exist without a purpose.
3. Refine the Use Cases - include requirements, constraints, complexity rating, notes and scenarios. This information unambiguously describes what the Use Case does, how it is executed and the constraints on its execution. Make sure the Use Case still meets the business process requirements. Include the definition of system tests for each use case to define the aceptance criteria for each use case. Also include some user acceptance test scripts to define how the user will test this functionality and what the acceptance criteria are.
4. From the inputs and outputs of the Business Process Model and the details of the use cases, begin to construct a domain model (high level business objects), sequence diagrams, collaboration diagrams and user interface models. These describe the 'things' in the new system, the way those things interact and the interface a user will use to execute use case scenarios.
5. From the domain model, the user interface model and the scenario diagrams create the Class Model. This is a precise specification of the objects in the system, their data or attributes and their behavior or operations. Domain objects may be abstracted into class hierarchies using inheritance. Scenario diagram messages will typically map to class operations. If an existing framework or design pattern is to be used, it may be possible to import existing model elements for use in the new system. For each class define unit tests and integration tests to thoroughly test i) that the class functions as specified internally and that ii) the class interacts with other related classes and components as expected.
6. As the Class Model develops it may be broken into discrete packages and components. A component represents a deployable chunk of software that collects the behaviour and data of one or more classes and exposes a strict interface to other consumers of its services. So from the Class Model a Component Model is built to define the logical packaging of classes. For each component define integration tests to confirm that the component's interface meets the specifcation given it in relation to other software elements.
7. Concurrent with the work you have already done, additional requirements should have been captured and documented. For example - Non Functional requirements, Performance requirements, Security requirements, responsibilities, release plans & etc. Collect these within the model and keep up to date as the model matures.
8. The Deployment model defines the physical architecture of the system. This work can be begun early to capture the physical deployment characteristics - what hardware, operating systems, network capabilities, interfaces and support software will make up the new system, where it will be deployed and what parameters apply to disaster recovery, reliability, back-ups and support. As the model develops the physical architecture will be updated to reflect the actual system being proposed.
9. Build the system: Take discrete pieces of the model and assign to one or more developers. In a Use Case driven build this will mean assigning a Use Case to the development team, having them build the screens, business objects, database tables, and related components necessary to execute that Use Case. As each Use Case is built it should be accompanied by completed unit, integration and system tests. A Component driven build may see discrete software components assigned to development teams for construction.
10. Track defects that emerge in the testing phases against the related model elements - eg. System test defects against Use Cases, Unit Test defects against classes & etc. Track any changes against the related model elements to manage 'scope creep'.
11. Update and refine the model as work proceeds - always assessing the impact of changes and model refinements on later work. Use an iterative approach to work through the design in discrete chunks, always assessing the current build, the forward requirements and any discoveries that come to light during development.
12.Deliver the complete and tested software into a test then production environment. If a phased delivery is being undertaken, then this migration of built software from test to production may occur several times over the life of the project.
No comments :
Post a Comment