Architecture of Object Oriented Software Engineering

Presentation on architecture of OOSE

1. Presentation on Architecture of OOSE Presented By Manoj Saru (Roll no. 49 – MSc Batch 2077) Sandesh Jonchhe (Roll no. 56 – MSc Batch 2077)

2. Contents 6.1. Introduction 6.2. System development in model building 6.4. Requirement model 6.3. Model Architecture

3. Contents ( Contd …) 6.5. Analysis model 6.6. The design model 6.8. Test model 6.7. The implementation model

4. 6.1. Introduction Chapter discusses the architecture of the pyramid It provides a reason and motivation for the models created and the concepts used when working with OOSE Fig: Layer of OOSE

5. 6.1.1 System development The concept ‘System development’ is used to describe the work that occurs when we develop computer support to aid an organization . When the requirement for a system is identified, system development begins – in this what one wishes to obtain from the system is specified. If the system is to be developed by someone outside the organization, specification is used for quotations and ordering of the system; similarly if the system is to be developed internally the specifications is used to plan and control the development process. From the requirement specification the system is developed and delivered with the required quality, and made as effective as possible. After the delivery of the system has been made, its operation phase begins which comprises of large amount of maintenance and further system development, and may span some decades.

6. 6.1.2 Object orientation, conceptual modeling and block design These three techniques have all been used for a long time, have this been background technologies for OOSE. Object oriented programming started with Simula , which was developed at the Norwegan Computing Center during the 1960s. It was developed initially as an extension of ALGOL to handle simulation applications. The real breakthrough was due to object oriented programing being very suitable when developing graphical user interfaces, GUIs. Such systems are difficult to describe with traditional programming languages. The concepts we have borrowed are mainly the idea of encapsulation, inheritance and the relationship between classes and instances.

7. 6.1.2 Object orientation, conceptual modeling and block design ( Contd …) Conceptual modeling has been used in different context since it came to life in the 1970s, such as analysis of information management systems and organization theory. The aim is to create models of the system or organization to be analyzed. Depending on which system one wishes to model, different conceptual models are created When information handling is central in a model, it is often used as a synonym for data modeling and is often used together with discussion of structuring and use of databases. The models that are developed are used mainly to understand the system and to obtain a good system architecture.

8. 6.1.2 Object orientation, conceptual modeling and block design ( Contd …) Block design originates from LM Ericsson and was developed beginning in the 1960s It is now in widespread use over the whole telecommunication area The ideas were developed from considering how one designed hardware – this was constructed using modules with certain functionality being considered together with well-defined interface. Same thing should be able to be done with software; collect together programs and data into modules (blocks) and describe their mutual communication with signals. By means of working with blocks, it was easier to change and introduce new functionality during operation; a new block is loaded and only one pointer is readdressed to point to t he new block.

9. 6.2 System development is model building System development is a complex task and several different aspects must be taken into consideration. The end result should be a reliable computer program that performs its task properly. For very small program we can take the requirements and write the program directly, but this would be a rare task when it comes to bigger programs/systems. What needs to be done is handle the complexity in an organized way. We do this by working with different models, each focusing on a certain aspect of the system.

10. 6.2 System development is model building ( Contd …) We work with five different models, which are The requirement model aims at capturing the functional requirements The analysis model aims at giving the system a robust and changeable object structure The design model aims at adopting and refining the object structure to the current implementation environment The implementation model aims at implementing the system The test model aims at verifying the system

11. Each model tries to capture some part or aspect of the system to be built To capture right from the start all the functional requirements of the system from a user perspective is requirements model . Here we describe how a potential user will use the system. When the model becomes stable, the system is structured from a logical perspective into a structure that is robust and above all maintainable during the system life cycle which is done by analysis model 6.2 System development is model building ( Contd …)

12. When we have developed an ideal structure, we adopt this maintainable structure with as little disturbance as possible in design model . When all of these decisions are made and the application further refined and formalized, the implementation model is gradually developed Finally the test model is developed to support the verification of the system developed which mainly involves documentation of test specifications and test results. 6.2 System development is model building ( Contd …)

13. 6.2.3 Development processes From the requirement specification the system is developed in a first version Almost all systems will then be further developed continuously, including maintenance of the system. Maintenance will of course also include analysis of new requirement. In reality development process is a number of different waterfalls (as discussed in chapter 2)

14. 6.2.3 Development processes ( Contd …) Fig: Processes intersect several waterfalls

15. 6.2.3 Development processes ( Contd …) Instead of focusing on how a specific project should be driven, the focus of the process is how a certain product should be developed and maintained during its entire life cycle. This means instead of describing a project in a waterfall description we have to divide the development work for a specific product into processes, where each of these processes describe one activity of the management of a product. The process work highly interactively Each process handles a specific activity of the system development In his manner, the product will be managed by a number of processes. Each process can in its turn consist of a number of communicating subprocesses.

16. 6.2.4 Processes and models Fig: Main processes and their relations In analysis process – requirement models and analysis model are developed In construction process – design model and implementation model are developed In testing process – test model is developed Component development process develops and maintains components to be used mainly during construction

17. 6.3 Model architecture The work is concerned with both identifying and describing objects in a certain information space, and with building models using these objects. All the models built during development of OOSE are build using objects ie with the help of objects, we build object models. For each model we develop, there exist different types of objects. By modeling with objects in all models, we gain all the benefits of object-orientation, namely locality of changes, encapsulation, reuse and so on. When one evaluates how the system needs to handle these objects, one can decide whether the object should be included or left out of the model being created. An object can be perfectly right for one model, but totally wrong in another. This means that an object must be placed in a context to see whether it is an appropriate object. Therefore, what is really of interest is how an object works with other objects and under what conditions.

18. 6.3 Model architecture (Contd...) The most important criterion for a good object model is that it should be robust for modifications and help the understanding of the system. As we know for certain that all systems we build will be modified, we must create a robust model structure. Therefore we must analyze how modifications will affect the system. The development process must therefore be designed so that it results in a sound and robust structure as fast as possible. Reduces the risk of having to change the system structure at a later stage and it should also force us to a sound and understandable structure.

19. 6.4 Requirements model Is determined totally by user’s functional requirements, often resulting in that the modifications will be local, as they often depend on how a user’s perspective gets modified. The first transformation made is from the requirement specification to the requirement model The requirement model can be regarded as formulating the functional requirement specification based on the needs from the system users. The model consists of A use case model Interface descriptions A problem domain model

20. 6.4.1 Actors and use cases The use case model uses actors and use cases. The actors represent what interacts with the system. As actors represent what is outside the system, we do not describe them in detail. Actors are not like other objects in the respect that their actions are non deterministic. We differentiate between actors and users. User is the actual person who uses the system Actor represents certain role that a user can play We regard actor as a class and users as instances of this class. These instances exist only when the user does something to the system. The same person can thus appear as instances of several different actors.

21. 6.4.1 Actors and use cases ( Contd …) An instance of an actor does a number of different operations to the system. When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case. An example of a use case could be to Acknowledge a flight to be performed by a Pilot. Each use case is a specific way of using the system and every execution of the use case may be viewed as an instance of the use case.

22. 6.4.1 Actors and use cases (Contd...) Example of a use case model. The system is bounded by a b ox. Each actor is represented by a person outside the box, while the use cases are represented as ellipses inside the box .

23. 6.4.2 Use case driven design As we design this way, the system model will be use case driven. When we wish to change the system behavior, we remodel the appropriate actor and use case. The whole system architecture will be controlled from what the users wish to do with the system. Another important characteristic of the requirements model is that we can discuss with the users and find out their requirements and preferences. As we have traceability through all models, we will be able to modify the system for new requirements. (which use case to modify by asking user) Since this is the first model to be developed, we can thus evaluate whether the users are pleased with what we are about to design, before we start to build the actual system

24. 6.4.2 Use case driven design ( Contd …) S The use case model will control the formation of all other models. It is developed in cooperation with the domain object model and it may be expressed in terms of domain objects.

25. 6.4.2 Use case driven design ( Contd …) S The functionality specified by the use cases is then structured into a logical, robust but implementation environment-independent model The analysis model, that is stable to changes is adapted to the actual implementation environment and further refined in the design models using the use cases to describe how the use case flow over the design objects. The use cases will then be implemented by the source code in the implementation model. Finally the use cases will give us a tool when testing the system. It will also give us support when writing manuals and other operation instructions

26. 6.5 Analysis model Analysis model aims at giving the system a robust and changeable object structure. The system is structured from a logical perspective into a structure that is robust and, above all, maintainable during the system life cycle . In analysis model we assume an ideal implementation environment, i.e. we don’t take into consideration which DBMS to use, hardware or any particular language and so on. It reduce the complexity and focus more on giving the application a stable, robust and logical structure. The implementation environment will change during the life cycle. In analysis model we specify all the logical objects to be included in the system and how these are related and grouped.

27. 6.5 Analysis model ( Contd …) The idea behind the logical, stable, robust and maintainable structure is that the future changes in the system will not affect this logical structuring. Analysis model aim is to capture information, behavior and presentation of the system which covers the information space for analysis model. The information dimension specify the information held in the system, The behavior dimension specify the behavior of the system, The presentation dimension specify the details for presenting the system to the outside world. Behavior Information Presentation Fig: The dimension of the analysis model

28. 6.5 Analysis model ( Contd …) The analysis model is built by specifying objects in this information space. Many object-oriented analysis methods choose to have only one object type, but the object types we used in the analysis model are entity objects, interface objects and control objects Entity object models information in the system. Interface object models any interface of the system that is placed in an interface object. Control object models functionality or behavior related to the system. The reason that we need these three object types is that to have locality in changes of the system i.e., all changes will be local and affect only one object in the system helps to build more stable system. Entity object Interface object Control object

29. 6.5 Analysis model ( Contd …) The Analysis model is formed from the use case model and each use case will entirely divided into objects of these three types. In the requirement model we specify the entire functionality of the system. This functionality should now be structured to get a robust and extensible structure. Basically, we partition the use case according to the following principles: Those use case functionalities which are directly dependent on the system’s environment are placed in interface objects, Those functionalities dealing with the storage and handling of information are placed in the entity object, Functionalities specific to one or few use cases are placed in control objects. By performing this division, we obtain a structure which gives high localization of changes and thus less sensitivity to modifications. For instance, changes of an interface affect only one object, the interface object that handles this interface and changes of data format would affect only the entity object.

30. 6.5 Analysis model ( Contd …) Fig: The portioning of use case and allocated to the objects.

31. 6.6 The design model The design model aims at adopting and refining the object structure to the current implementation environment. Design model is a refinement and formalization of the analysis model where the initial work is to adapt to the actual implementation environment. In design model our goal is to refine it so far that it is straightforward to write the source code from it. Fig: The Dimension of the design model

32. 6.6 The design model ( Contd …) In design model we use the concept of a block to describe the intention of how the code should be produced. The blocks are the design objects and they are drawn as rectangle. One block normally aims to implementing one analysis object. We could use different types of blocks as well, for instance interface blocks , entity blocks and control blocks to highlight the traceability. Block

33. 6.6 The design model ( Contd …) We will try to map the design objects (Blocks) to the module concept used in the programming language we are implementing in. We describe how the block will communicate during execution by the use of stimuli . A stimulus is sent from one block to another to trigger an execution in the block. This execution may send new stimuli to other blocks. We use interaction diagrams to describe a sequence of stimuli and how they communicate by sending stimuli to each other. Fig: Interaction diagram.

34. 6.6 The design model ( Contd …) To able to manage the system more abstractly, we use the concept of subsystem. It helps to groups several objects together and to helps to manage its complexity. Fig: The transition from analysis model to Design model

35. 6.7 The implementation model The base for implementation is the design model where we specified the interface of each block and also have described the behavior of what is expected behind this interface. The implementation model aims at implementing the system. When all of the decisions are made and the application further refined and formalized, the implementation model is gradually developed. The implementation model implement the objects and also consists of the source code.

36. 6.8 The test model The test model aims at verifying the system. The testing process integrates the system, verifies it and decides whether it should be passed on for delivery. This mainly involves documentation of test specifications and test results. Fig: The testing process with its major components.

37. 6.9 Summary We have defined the concepts and the models that are developed when using OOSE. System development includes many activities during the system life cycle. When developing a product, it is essential to focus on all these activities. When having a life cycle view, one of the most important properties of a system is that the system is maintainable, i.e. changes can be made to the system at a reasonable cost. System development is a complex task and by building models at different levels can help to manage the complexity. Another important property is that we are able to trace changes from one object in one model to objects in another model.

38. Thank you