SOFTWARE ENGINEERING LECTURE 5

1. SOFTWARE ENGINEERING LECTURE 5 • Today:- An overview to OO Analysis and OO Design- Introduction of Assignment 2.

2. THE PROGRAMMING PARADIGM • The requirements specification should be as programming paradigm (such as OO, logic programming, etc.) independent as possible. • However, that’s where it stops. The system analysis methods and tools are oriented towards a programming paradigms (intentionally or not). • Usually the programming paradigm has been fixed before the analysis starts. Reasons for this include:- expertise in some paradigm,- client’s demands,- HW/SW platform

3. SYSTEM ANALYSIS METHODS • Analysis and Design are described in Pressman’s book both for the Object Oriented approach and the so called ”traditional approach” (separate descriptions for data and processing, procedural implementation language). • Choose a system analysis method, which:- communicates with the client, - you have tools for (no tools, no motivation),- supports your programming paradigm (no additional complicated transformations are required),- you are familiar with (or willing to learn)

4. EXAMPLE METHODS • Data Flow Diagrams • SA/SA (Structured Analysis/Structured Design) • Flowcharts • Object oriented methods • NIAM • ER-diagrams • Other conceptual modelling methods • Formal methods based on logic

5. TOOLS • Graphical is generally easier to use • Nowadays the selection of tools has improved • The tools should support also software design, implementation and modification - prefer an integrated or a compatible set of tools.

6. OO ANALYSIS AND DESIGN • There are several competing OO methods and OO design languages. • These are also introduced in Pressman’s book. • These methods share common ideas. We try to present these general ideas in today’s lecture.

7. SYSTEM ANALYSIS • In the analysis phase, we take the requirements and produce a model of the system. • The analysis model of the system describes the architecture of the system on a very rough level. • The analysis model does not describe the implementation, but rather the overall structure and functionalities of the system.

8. OO SYSTEM ANALYSIS • Object oriented system analysis produces an object oriented model of the system. • The model produced in OO system analysis needs not to be directly implementable. • The understandability and correctness of the model are key points in it.

9. OO SYSTEM ANALYSIS MODEL • The main products in the OO system analysis model are:- A class diagram- Descriptions of the classes- Scenarios created for the use cases • Classes may be divided into categories. • Re-usable classes may be identified.

10. FINDING CANDIDATE CLASSES • The candidate classes in the analysis model understandably come from the requirement specification. • The text in the specification can be analysed to find potential classes. • Generally, a noun in the requirement description corresponds to a potential class. • Adjectives may represent attributes of these candidate classes. • Verbs may represent methods of these candidate classes.

11. PERFORM OBJECT ANALYSIS • Identify subclasses and superclasses • Common attributes and naming may give hints for this. • Identify whole-part structures (aggregations) • Analyse the domain to identify re-usable classes. • Divide classes into subsystems. • Explain the role and motivation for the class.

12. BUILD SCENARIOS • Build a scenario for each use case. • The objects in the scenarios should be the objects identified of the analysis model obtained this far.

13. METHODS & STATE DIAGRAMS • The scenarios can now be used to identify methods for the objects in the analysis model. • The methods should have some understandable description. • The exceptions in the use cases (if not included in the scenarios) can be used to identify further methods. • Identifying the methods may give rise to new attributes. • Based on the identified methods and the attributes, it is possible to construct state diagrams for the objects.

14. FURTHER OBJECT ANALYSIS • After all these steps, analyse the analysis object model further. • The result should now describe the structure of the system to be built.

15. OBJECT ORIENTED DESIGN • Object oriented design should transform the analysis model into a model which can be implemented. • Object oriented design contains the following:- System design- Human interface design- Object design- Data management design- Process management design – control, priority,…

16. SYSTEM DESIGN • Divide the analysis model into subsystems • Identify hardware components • Identify processes – attach to hardware • Allocate subsystems to processes • Identify user interface components • Choose basic strategy for data management • Make sure that the overall system structure works and design a control mechanism for it.

17. HUMAN INTERFACE DESIGN • Specify human interface functionalities • Perform graphical design

18. OBJECT DESIGN • Transform the object model into something that can be implemented. • Generally, classes will be divided. • Implementable classes – efficiency considerations. • Describe method parameters and functionality. • Check attributes (generally, more will be added). • Create versions of the scenarios which use the classes obtained in this object design. • Iterate, until it seems to work.

19. DATA MANAGEMENT DESIGN • Identify persistent data. • Identify system parameter data. • Make a storage plan for these:- database type- database schema/storage plan- efficiency considerations