A BASIC OO SOFTWARE DEVELOPMENT PROCESS

1. A BASIC OO SOFTWARE DEVELOPMENT PROCESS • Earlier, we saw a number of different software lifecycle models. • Similarly, there exists different ways to develop object oriented (OO) software. • We will start with a very basic OO waterfall model as given in the textbooks. That model is ok, if there is no (relational) database and the software is not that big. • Later, we will study why this is typically only good for small non-database software. • We will also study how large-scale database-driven OO software should be developed. Software Engineering 2003 Jyrki Nummenmaa

2. The Waterfall Model for OO • The same model basically applies with V&V Requirement specification <- This is standard. Analysis & Design <- This is the main thing. Implementation <- This is done according to the design. This has some special issues, but I will talk --->about testing separately. Testing Maintenance We may talk about this separately. -> Software Engineering 2003 Jyrki Nummenmaa

3. Object Analysis And Design • The goal is to start from the requirements, and to come up with a description of the software (classes with their attributes and methods) which can be implemented in a fairly straightforward way. • Usually we talk about “analysis model” and “design model”. • Analysis model is something which, in principle, describes the system in OO terms, but we would not want to implement it as such, for reasons such as efficiency and maintainability. • Design model is something we want to implement. Software Engineering 2003 Jyrki Nummenmaa

4. Object Analysis • Goal: Start from the requirement specification and come up with • A description of the classes (commonly a class diagram, to be introduced later) • A description on how the use cases are to be executed using these classes (with some other UML diagrams such as sequence diagrams, also to be introduced later). • Methods: • “Meditation-type” methods which more or less means “no methods”. • Requirement specification text analysis. <- Our plan here! • Analysis of all possible technical documentation of an old system or other existing systems. • Possibly separate analysis of the domain (e.g. banking). Software Engineering 2003 Jyrki Nummenmaa

5. Object Design - Architecture • This typically starts with something called “architectural design”, which in a way describes the basic solutions and or models, which the design is going to follow. • Here, we identify different processes, which possibly run on different computers. • There is a number of “design styles”, which may be applied. • The technology and the software development tools may probably have a major impact on the architectural solutions. Software Engineering 2003 Jyrki Nummenmaa

6. Object Design • Once the architectural decisions have been made, the analysis model is developed into a model describing the classes that we are actually going to implement. • The UML diagram types are probably mostly the same as in analysis, but new classes, methods and attributes are introduced for the implementation. Software Engineering 2003 Jyrki Nummenmaa

7. Next time • We will go through this process based on an example. Software Engineering 2003 Jyrki Nummenmaa