OBJECT-ORIENTED SOFTWARE DEVELOPMENT Using OBJECT MODELING TECHNIQUE () Ahmed Hayajneh, May 2003 1
1 Introduction One of the most popular object-oriented development techniques today is the Object Modeling Technique () developed by Rumbaugh et al. [1]. It is primarily used by system and software developers supporting full life-cycle development, targeting objectoriented implementations. Because of its simple core notation, has proven easy to understand, to draw, and to use. It continues to be successful in many application domains: telecommunication, transportation, compilers, etc. The popular Object Modeling Technique () has been used in many real-world problems. The object-oriented paradigm using the, spans the entire development process, so there is no need to transform from one type of model to another. This is a key benefit of the [2]. 1.1 Model graphically defines a system through three kinds of model: object model, dynamic model and functional model. The Notation is given in Appendix. Object model (OM) The object model is the most important model. It identifies the object classes in the system and their relationships, as well as their attributes and operations (methods). It represents the static structure of the system. The object model is represented graphically by a class diagram. Dynamic model (DM) The dynamic model indicates the dynamics of the objects and their changes in state. By exploring the behavior of the objects over time and the flow of control and events among the objects, the dynamic model captures the essential behavior of the system. Scenarios are captured in event trace diagrams. These diagrams, along with state diagrams (state charts), compose the dynamic model. Functional model (FM) The functional model is a data flow diagram (DFD) of the system and describes what the system does, but not how it is done. A DFD is a network representation of the system showing the functional relationships of the values that computed by a system. Relationship among models Each model describes one aspect of the system but contains references to the other models. The object model describes the data structure that the dynamic and functional models operate on. The operations in the object model correspond to events in the dynamic model and functions in the functional model. The dynamic model describes the control structure of Ahmed Hayajneh, May 2003 2
objects. It shows decisions which depend on object values and which cause actions that change object values and invoke functions. The functional model describes functions invoked by operations in the object model and actions in the dynamic model. Functions operate on data values specified by the object model. The functional model also shows constraints on object values. Additional Constructs has several additional constructs and diagrams that are often useful, e.g., problem statements and use cases. They are used to establish system boundaries, requirements, and to specify detailed behavior [3]. 1.2 Phases of Object-Oriented Development Process The object-oriented development process using is shown in Fig. 1 [2]. Analysis understand and model the application and its domain. System Design determine the overall system architecture in terms of subsystem, concurrent tasks and data storage. Object Design refine then optimize the analysis model, from applications to computer concepts. Coding implement the object classes in target programming language. Testing incremental - at any stage system comprises tested and untested object classes. Testing is based on the scenarios developed as part of the dynamic modeling process. Each phase of the process transforms some inputs to outputs, starting at a high level of abstraction and progressing to a more detailed level of abstraction that ultimately represents the problem solution (Fig. 2). Ahmed Hayajneh, May 2003 3
2 Analysis 2.1 Object Model The identifies the following steps in constructing an object model: 1. Develop a problem statement. 2. Identify the object classes. 3. Discard unnecessary and incorrect classes. 4. Prepare a data dictionary. 5. Identify associations between object classes. 6. Discard unnecessary and incorrect associations. 7. Identify attributes of the object classes. 8. Discard unnecessary and incorrect attributes. 9. Use inheritance to share common structure. 10. Traverse access paths to identify deficiency. 2.2 Dynamic Model The dynamic model is concerned with changes to objects and their relationships over time. It is used for systems with important dynamic behavior, e.g. interactive and real-time systems. The dynamic model shows possible control flows through the system, while the object model shows possible information flows. Steps to build a dynamic model: 1. Identify use cases and prepare scenarios of typical interaction sequences. 2. Identify events between objects and prepare an event trace diagram for each scenario. 3. Prepare an event flow diagram for the system. 4. Develop state diagrams for classes with important dynamic behavior. 5. Check for consistency and completeness of events shared among the state Ahmed Hayajneh, May 2003 4
diagrams. 2.3 Functional Model The functional model consists entirely of data flow diagrams (DFDs) and constraints. Data flow diagrams consist of processes, data flows, actors, and data stores. A process transforms input data values into output data values. A process is presented as an ellipse, with the name of the process inside the ellipse. A data flow shows the flow of data through a network of processes. An actor, drawn as a rectangle, lines on the boundary of the DFD and terminates the flow of data as a source or sink of data. Actors are objects. A data store is a repository for the temporary storing of data. A data store is represented as a pair of parallel lines containing the name of a data store. Data stores may also be objects. Steps to build a functional model: 1. Identify input and output values. 2. Use data flow diagrams as needed to show functional dependencies. 3. Describe what each function does. 4. Identify constraints. 5. Specify optimization criteria. 3 System Design During system design, the high level structure of the system is chosen. The decisions that will be addressed during system design are [1]: 1. Organize the system into subsystems. 2. Identify concurrency. 3. Allocate subsystems to processors and tasks. 4. Choose the strategy for implementing data stores in terms of data structures, files, and databases. 5. Identify global resources and determine mechanisms for controlling access to them. 6. Choose an approach to implementing software control: Use the location within the program to hold state, or Directly implement a state machine, or Use concurrent tasks. 7. Consider boundary conditions. 8. Establish trade-off priorities. 4 Object Design Object design is concerned with fully specifying the existing and remaining classes, associations, attributes, and operations necessary for implementing a solution to the problem. Operations and data structures are fully defined along with any internal objects needed for implementation. In essence, all of the details for fully specifying how the problem will be solved are specified during object design [2]. The remaining classes Ahmed Hayajneh, May 2003 5
have a direct relationship with the development system as well as the class library. 1. Obtain operations for the object model from the other models: Find an operation for each process in the functional model. Define an operation for each event in the dynamic model, depending on the implementation of the control. Design algorithms to implement operations: Choose algorithms that minimize the cost of implementing operations. Select data structures appropriate to the algorithms. Define new internal classes and operations as necessary. Assign responsibility for operations that are not clearly associated with a single class. 3. Optimize access paths to data: Add redundant associations to minimize access cost and maximize convenience. Rearrange the computation for greater efficiency. Save derived values to avoid recomputation of complicated expressions. 4. Implement software control by fleshing out the approach chosen during system design. 5. Adjust class structure to increase inheritance: Rearrange and adjust classes and operations to increase inheritance. Abstract common behavior out of groups of classes. Use delegation to share behavior where inheritance is semantically invalid. 6. Design implementation of associations: Analyze the traversal of associations. Implement each association as a distinct object or by adding object-valued attributes to ore or both classes in the association. 7. Determine the exact representation of object attributes. 8. Package classes and associations into modules. 5 Implementation Implementation of the design is a straightforward matter of translating the design into code, since most difficult decisions are made during design. The code should be a simple translation of the design decisions into the peculiarities of a particular language. Decisions do have to be made while writing code, but each one should affect only a small part of the program so they can be changed easily. Object-oriented languages and non-object-oriented languages, as well as database systems can be used for implementation [1]. Implementation of an object-oriented design is easiest using an object-oriented language, but even object-oriented languages vary in their degree of support for object-oriented concepts. Even when a non-objectoriented language must be used, an object-oriented design is beneficial. Object-oriented concepts can be mapped into non-object-oriented language constructs. Use of a non objectoriented language requires greater care and discipline to preserve the object-oriented structure of the program. When the main concern is access to persistent data, rather than the operations on the data, a database is often the appropriate form of Ahmed Hayajneh, May 2003 6
implementation. 6 Testing Testing is an activity to verify that a correct system is being built. The implementation and testing are partly involved during the analysis and design. This means that analysis, design, implementation and testing are very interleaved activities performed in an incremental fashion. Testing may be done in various way: in a top-down fashion, a bottom-up fashion or in a per use case fashion. The relationship among the units is in form of so called Client- Server. A client requests a service from a server unit and the server unit provides the service and responds with a result. A bottom-up approach may be preferable at the lower levels, so that when the first unit (module) is certified, its direct clients can be certified. Then the next level of clients can be certified and so on. Testing may be performed at different levels: unit testing, integration testing and system testing. A unit test is the lowest level of testing. In a traditional system a unit test is often a test of procedures and subroutines. In object-oriented software it concerns classes, which implies that unit tests in object-oriented systems are carried out at a higher level. Doing a unit test of object-oriented code is therefore more complex than testing ordinary procedural code, as a unit is not just a set of routines, but also has an encapsulated state which may affect the behavior and correctness of the unit. Also, concepts like inheritance and polymorphism lead to additional complexity in testing, since we may need to retest both the inherited and override methods at different levels in the inheritance hierarchy [4]. Integration testing is to test whether different units that have been developed are working together properly. It includes the testing of modules, use cases, subsystems and the entire system. Integration tests are performed several times on different levels. The use case constitute an excellent tool for the integration test, and integration testing is performed by testing each use case one at a time. When all use cases have been tested separately, the entire system is tested as a whole. In system testing several use cases should be tested in parallel, both synchronized and unsynchronized. Ahmed Hayajneh, May 2003 7
References: [1] Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy and W. Lorensen (1991). Object-Oriented Modeling and Design. Prentice-Hall International Editions, New Jersey. [2] Derr, K.W. (1995). Apply : A Practical Step-by-step Guide to Using the Object Modeling Technique. SIGS Books, New York. [3] Martin, L. (1996). Succeeding with the Booch and Methods: A Practical Approach. Addison-Wesley, Menlo Park, California. [4] Jacobson, I., M. Christerson, P. Jonsson and G. Overgaard (1994). Object- Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Reading, MA. Ahmed Hayajneh, May 2003 8
Ahmed Hayajneh, May 2003 9
Ahmed Hayajneh, May 2003 10
Ahmed Hayajneh, May 2003 11
Ahmed Hayajneh, May 2003 12