1 / 19

SOFTWARE ENGINEERING LECTURE 5

SOFTWARE ENGINEERING LECTURE 5. Today: - An overview to OO Analysis and OO Design - Introduction of Assignment 2. THE PROGRAMMING PARADIGM. The requirements specification should be as programming paradigm (such as OO, logic programming, etc.) independent as possible.

maris
Download Presentation

SOFTWARE ENGINEERING LECTURE 5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related