Presentation on theme: "15.1.2003Software Engineering 2003 Jyrki Nummenmaa 1 A BASIC OO SOFTWARE DEVELOPMENT PROCESS Earlier, we saw a number of different software lifecycle models."— Presentation transcript:
15.1.2003Software Engineering 2003 Jyrki Nummenmaa 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.
15.1.2003Software Engineering 2003 Jyrki Nummenmaa 2 The Waterfall Model for OO The same model basically applies with V&V Requirement specification Maintenance Testing Implementation Analysis & Design <- This is standard. <- This is the main thing. <- This is done according to the design. This has some special issues, but I will talk ---> about testing separately. We may talk about this separately. ->
15.1.2003Software 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.
15.1.2003Software 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).
15.1.2003Software 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.
15.1.2003Software 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.
15.1.2003Software Engineering 2003 Jyrki Nummenmaa 7 Next time We will go through this process based on an example.