| click here for POSD home page |
The refinement steps for the example are listed below:
The reader is advised to study the refinement steps in serial order as they are presented below. The reader may later re-visit particular steps by clicking on entries in the above list.
The tool starts the stepwise refinement process by asking the designer for a start position for the process. For this example assume that the designer provides the following start position.
In this diagram the circles represent systems. A line between two circles indicates that the systems represented by the circles interact with each other. Shaded circles represent sets of similar systems. Shaded lines represent sets of similar interactions between sets of similar systems. Sets of systems have a * at the beginning of their identifiers.
The designer then asks the tool to take *construction_company (the set of construction companies) as the first focus for a refinement step. The tool provides a diagram showing *construction_company and all the systems with which it interacts.
The tool can also (if requested by the designer) provide the design for *construction_company.
As the diagram above shows the tool simply extracts one company from the set of companies. The company extracted is given the identifier - construction_company_c. The suffix c is used to distinguish that company (and later its components) from all other companies in the set of companies (and their components). The set of all companies (except for construction_company_c) is given the identifier - *construction_company_¬c.
The designer now asks the tool to take construction_company_c as the next focus for a refinement step. The tool provides a diagram showing construction_company_c and all the systems with which it interacts.
The designer then provides the tool with a design for construction_company_c.
The designer has split construction_company_c into two components, *construction_project_c (the set of construction projects in which construction_company_c is involved) and company_legacy_c (the resources , information, knowledge and skills which construction_company_c shares between all projects).
Note that the two components inherit the suffix c. This would, for instance, enable company_legacy_c in construction_company_c to be distinguished from the similar component, company_legacy_d, in construction_company_d, though this will not be necessary in this example.
Note that the designer has put arrows on two of the lines in the design. An arrow on a line means that the interaction represented by that line is always initiated from the source end of the arrow. Thus *construction_customer always initiates the interaction with *construction_project_c.
The designer now asks the tool to take *construction_customer (the set of construction customers) as the next focus for a refinement step. The tool provides a diagram showing *construction_customer and all the systems with which it interacts.
The tool can also (if requested by the designer) provide the design for *construction_customer.
As the diagram shows the tool extracts one customer (construction_customer_u) from the set of construction customers, leaving the set of customers (except for this customer) as *construction_customer_¬u.
The designer now asks the tool to take *construction_project_c (the set of projects of construction_company_c) as the next focus for a refinement step. The tool provides a diagram showing *construction_project_c and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *construction_project_c. This will involve extracting one project from the set of construction projects (just as it did earlier for the sets of construction companies and construction customers). Without further guidance the tool can produce the following diagram
However, each construction project has just one customer, so the designer needs to modify the diagram by removing one line and adding the suffix u to the identifier of the project. The result is the following diagram.
Construction_project_cup has three suffixes to show that it is project p within customer u within company c.
In a real demonstration of the tool, it may not be necessary to display all of the suffixes, some of them will be clear from the context provided by the design process.
The designer now asks the tool to take construction_project_cup as the next focus for a refinement step. The tool provides a diagram showing construction_project_cup and all the systems with which it interacts.
The designer then provides a design for construction_project_cup.
The designer has decided to split construction_project_cup into two components, project_supply_cup and project_activities_cup. The designer chose this design because the object of the design exercise is to design the project supply component in detail, so this refinement has separated the part of the construction_project_cup which is of interest to the designer (project_supply_cup) from the part that is of less interest (project_activities_cup).
The designer now asks the tool to take company_legacy_c as the next focus for a refinement step. The tool provides a diagram showing company_legacy_c and all the systems with which it interacts.
The designer then provides a design for company_legacy_c.
The designer has decided to split the company_legacy_c component into four components, *assess_suppliers_c (responsible for all assessment of suppliers), materials_store_c (the central store of supplies purchased in bulk or left over from other projects), plant_inventory_c (the plant (diggers, bulldozers, etc.) owned or rented by the construction company), customer_relations_c (marketing and sales and the good (or bad) relations with existing and past customers).
The designer now asks the tool to take *construction_supplier (the set of construction suppliers) as the next focus for a refinement step. The tool provides a diagram showing *construction_supplier and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *construction_supplier.
As the diagram shows the tool extracts one supplier (construction_supplier_s) from the set of construction customers, leaving the set of customers (except for this customer) as *construction_supplier_¬s.
The designer now asks the tool to take project_supply_cup as the next focus for a refinement step. The tool provides a diagram showing project_supply_cup and all the systems with which it interacts.
The designer then provides a design for project_supply_cup.
The designer has decided to split the project_supply_cup component into five components to reflect the five stages in the supply process - getting rough quotes from suppliers when tendering (to the customer) for the project, getting firm quotes before ordering supplies, and purchasing, delivering and paying for the supplies.
Note that each of these five components is in fact a set of components. For instance *purchase_supply_cup is a set of purchase_supply components. There is one of these components for each supply purchased. Note also that each purchase_supply component may interact with the other purchase_supply components (the reason for this will be shown later). This is indicated by the small loop on *purchase_supply_cup.
The designer now asks the tool to take *assess_supplier_c as the next focus for a refinement step. The tool provides a diagram showing *assess_supplier_c and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *assess_supplier_c. However the tool needs to be told that it should use the suffix s (rather than some new suffix) for the assess_supplier_cs component which it extracts from *assess_supplier_c. This is because there is to be one assess_supplier_cs component for each construction_supplier_s. Given this information the tool can generate the following diagram.
Note that the tool has recognised that the line joining assess_supplier_cs to *construction_supplier_¬s is not required. This is because assess_supplier_cs assesses construction_supplier_s and no other supplier. For similar reasons the line joining *assess_supplier_c¬s to construction_supplier_s is not required.
The designer now asks the tool to take *quote_for_tender_cup as the next focus for a refinement step. The tool provides a diagram showing *quote_for_tender_cup and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *quote_for_tender_cup. As for the previous refinement stage, the tool needs to be told to give the quote_for_tender_cups the suffix s (rather than some new suffix), and this tells it to leave out some lines, resulting in the following diagram.
The designer now asks the tool to take *quote_for_purchase_cup as the next focus for a refinement step. The tool provides a diagram showing *quote_for_purchase_cup and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *quote_for_purchase_cup. As for the previous refinement stages, the tool needs to be told to give the quote_for_purchase_cups the suffix s (rather than some new suffix), and this tells it to leave out some lines, resulting in the following diagram.
The designer now asks the tool to take *purchase_supply_cup as the next focus for a refinement step. The tool provides a diagram showing *purchase_supply_cup and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *purchase_supply_cup. As for the previous refinement stages, the tool needs to be told to give the purchase_supply_cups the suffix s (rather than some new suffix), and this tells it to leave out some lines, resulting in the following diagram.
The designer now asks the tool to take *deliver_supply_cup as the next focus for a refinement step. The tool provides a diagram showing *deliver_supply_cup and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *deliver_supply_cup. As for the previous refinement stages, the tool needs to be told to give the deliver_supply_cups the suffix s (rather than some new suffix), and this tells it to leave out some lines, resulting in the following diagram.
The designer now asks the tool to take *pay_for_supply_cup as the next focus for a refinement step. The tool provides a diagram showing *pay_for_supply_cup and all the systems with which it interacts.
The tool can also (if requested by the designer) provide a design for *pay_for_supply_cup. As for the previous refinement stages, the tool needs to be told to give the pay _for_supply_cups the suffix s (rather than some new suffix), and this tells it to leave out some lines, resulting in the following diagram.
The designer now asks the tool to take assess_supplier_cs as the next focus for a refinement step. The tool provides a diagram showing assess_supplier_cs and all the systems with which it interacts.
The designer then provides a design for assess_supplier_c.
The designer now asks the tool to take arrange_assessment_cs as the next focus for a refinement step. The tool provides a diagram showing arrange_assessment_cs and all the systems with which it interacts.
The designer then provides a design for arrange_assessment_cs.
The designer now asks the tool to take use_assessment_cs as the next focus for a refinement step. The tool provides a diagram showing use_assessment_cs and all the systems with which it interacts.
The designer then provides a design for use_assessment_cs.
The designer now asks the tool to take quote_for_tender_cups as the next focus for a refinement step. The tool provides a diagram showing quote_for_tender_cups and all the systems with which it interacts.
and so on until reaching an already implemented components.
last revision: 21st June 1997