Mann Creek Software

Object-Oriented Software Engineering

Jacobson divides the software development process into seven activities (requirements capturing, requirements analysis, ideal design, real design, implementation, testing, and beta testing [from Jacobson, 1995]). The following object diagrams show some of the business system objects that participate therein.

Requirements Capturing: Captures requirements imposed on the information system. Input is from all the interface objects in the business-system model that interact with customers in any way (generates functional and nonfunctional requirements). The Resource Collector is an abstract business system interface object that is inherited by all these interface objects. Product Orderer processes collected information. All suggestions are stored in the Wish List. Results are a prioritized list of requirements (including rough time estimates).

Requirements Analysis: Defines the functionality that the information system should have. The major work product is an IS use case model, which is developed from the object model of the business to be supported if it exists (otherwise developed by visualizing the information system to potential IS users). The Product Orderer initiates the Requirements Analyst to develop a Requirements Specification according to the Requirements List priorities. In an iterative fashion, for each Requirements List item, the Requirements Analyst (1) identifies actors, (2) identifies IS use cases based on actors needs, (3) describes the IS use cases in detail, and (4) describes the IS user interfaces in detail (general procedure is to first develop sketches of the user interface and then to build prototypes that insure the capture of the users' requirements and demonstrate the intended IS properties).

Ideal Design: Shows how the information system should be structured to absorb the inevitable functional requirements changes. The Ideal Designer uses the IS use case model and the Requirements Specifications as a basis for building an ideal object model, (0) identifying IS entity objects to represent things and occurrences in the use case model. In an iterative fashion, for each IS use case (starting when the Requirements Analyst has a first version of the use case model), the Ideal Designer then (1) identifies IS objects needed to perform the flow of events (proceeding from actors to interface objects to control objects to additional entity objects), (2) describes how each IS use case is performed (in terms of IS objects), (3) makes the object model consistent from a global IS viewpoint (merging similar objects from separate use cases, making object model clear and logical), and (4) for each IS object, find and describe all responsibilities by examining its role in each use case.

Real Design: Shows how to realize the use case model, given a certain implementation environment. Uses the use case descriptions, ideal object descriptions, implementation environment specifications, and Requirements Specifications to generate a real design model. Using the Ideal Object Model as a basis, the Real Designer (1) adapts the model to the implementation environment (implementation language, DBMS, existing hardware/software), (2) distributes behavior to real IS objects by developing interaction diagrams for each use case (known as use case design), (3) identifies operations and attributes for each real object by studying the interaction diagrams.

Implementation: Defines the interfaces between the real objects, and the behavior expected behind the interfaces. It is desirable to have a one-to-one match between a real object and its implementation (in the form of classes), but this may not be the case if using non-object oriented implementation tools (e.g. RDBMS). The person responsible for the real object design will also implement it, using primarily the Real Object Model, but also the Use Case Model and the Requirements Specification. The Real Designer (1) transforms the different real objects into code (using components [fully implemented parts, e.g. visual interface parts] and frameworks [subsystems designed for reuse and to be extended, e.g. class libraries, object-to-relational DB translation, and distributed computing environments] as much as possible), and (2) tests each implemented real object to verify the specified behavior and the internal structure (unit testing).

Testing: Checks whether the developed system performance agrees with the specifications (system verification). Testing is a large part of the development process, typically 25% to 50% of the total development cost, and should commence as soon as user interface sketches and prototypes are developed during Requirements Analysis. The Tester (1) develops test documents based on use cases, (2) documents test results, (3) determines, if faulty, where responsibility lies (real design, ideal design, or requirements analysis), and (4) communicates testing results back to Requirements Analyst and Real Designer.

Beta Testing: Ensures the quality of the developed product by making it (along with manuals) available to a carefully selected subset of customers before product release. Validates that the right product has been produced. The Beta Test Handler (1) produces a beta release of the product (executable and manuals), (2) delivers the Beta Product to Beta User, (3) records all comments of Beta User, and (4) communicates any serious problems back to Tester.