Section C.2. ...with a Sprinkling of OOSE...

C.2. ...with a Sprinkling of OOSE...

Ivar Jacobson and his Object-Oriented Software Engineering (OOSE) approach is probably best known for the revolutionary technique of mapping requirements to object-oriented software designs, called use cases. There was a definite focus in OOSE to accurately capture and model the problem domain, and use cases were a key technique in achieving this as part of a requirements model.

OOSE was not just about requirements, though; it also had corresponding models for analysis and design. The analysis model in OOSE was one in which object relationships could be modeled. It drew distinctions between entity objects that contain data, control objects that control other objects, and interface objects that interact with users or other external systems. UML has inherited these types of objects, and they are particularly popular on sequence diagrams (see Chapter 7).

The design model allowed you to describe how the system behaves using state transition and interaction diagrams, whichalthough the notation has changedare still present to some extent in UML today. Communication diagrams are covered in Chapter 8; state machine diagrams are covered in Chapter 14.

To complete the picture, the OOSE also specified implementation and test models. An implementation model captured how use cases were mapped to the underlying system implementation and the test model closed the loop by showing how use cases could drive the development of a system's tests.

Despite all of these various models, use cases are the thing that OOSE will be most noted for; see Figure C-2 for an example. UML has gone through various iterations over the years, but of all the UML constructs, use cases is the one technique that's remained unchanged.

Figure C-2. The OOSE use case notation describes three use cases within a system and the two outside influencesactorsthat interact with those use cases