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

Slides:



Advertisements
Similar presentations
Ch 3 System Development Environment
Advertisements

Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Introduction To System Analysis and Design
Component-Level Design
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Chapter 6 Methodology Conceptual Databases Design Transparencies © Pearson Education Limited 1995, 2005.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Lecture Fourteen Methodology - Conceptual Database Design
Component-Level Design
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Methodology Conceptual Database Design
1 A Student Guide to Object- Orientated Development Chapter 9 Design.
CSCI 639 Topics in Software Engineering Assignment #4 Fall 2006.
Modeling & Designing the Database
Object Oriented Analysis and Design Using the UML
Chapter 1 The Systems Development Environment
Chapter 1 The Systems Development Environment
Introduction To System Analysis and design
The Systems Development Environment. Learning Objectives Define information systems analysis and design. Describe the different types of information systems.
Lesson 7 Guide for Software Design Description (SDD)
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Chapter 1 The Systems Development Environment
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
The Software Development Life Cycle: An Overview Presented by Maxwell Drew and Dan Kaiser Southwest State University Computer Science Program.
Chapter 1: The Object-Oriented Systems Development Environment Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,
CSC271 Database Systems Lecture # 4.
ITEC224 Database Programming
Chapter 1 The Systems Development Environment Modern Systems Analysis and Design Sixth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Methodology - Conceptual Database Design Transparencies
Software School of Hunan University Database Systems Design Part III Section 5 Design Methodology.
Methodology Conceptual Databases Design
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
CSCI 3140 Module 2 – Conceptual Database Design Theodore Chiasson Dalhousie University.
1 Chapter 15 Methodology Conceptual Databases Design Transparencies Last Updated: April 2011 By M. Arief
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Ch:10 Component Level Design Unit 4. What is Component? A component is a modular building block for computer software Because components reside within.
Unified Modeling Language, Version 2.0
5 Systems Analysis and Design in a Changing World, Fourth Edition.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
Chapter 1 The Systems Development Environment Modern Systems Analysis and Design Sixth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Software Design Deriving a solution which satisfies software requirements.
Methodology - Conceptual Database Design. 2 Design Methodology u Structured approach that uses procedures, techniques, tools, and documentation aids to.
1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.
Structural Modeling. Objectives O Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. O Understand.
Systems Analysis and Design in a Changing World, 3rd Edition
The Systems Development Life Cycle
Methodology - Conceptual Database Design
1 COMP 350: Object Oriented Analysis and Design Lecture 1Introduction References: Craig Larman Chapter 1.
Lecture 6: Structural Modeling
Part4 Methodology of Database Design Chapter 07- Overview of Conceptual Database Design Lu Wei College of Software and Microelectronics Northwestern Polytechnical.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
1 Unified Modeling Language, Version 2.0 Chapter 2.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
CMSC 345 Fall 2000 OO Design. Characteristics of OOD Objects are abstractions of real-world or system entities and manage themselves Objects are independent.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 SYS366 Week 1 - Lecture 1 Introduction to Systems.
Software Engineering Lecture 10: System Engineering.
Basic Characteristics of Object-Oriented Systems
Methodology Conceptual Databases Design
UNIT 1.
Methodology Conceptual Database Design
Object-Oriented Design
Software Design Lecture : 14.
Copyright 2007 Oxford Consulting, Ltd
Methodology Conceptual Databases Design
Chapter 10 – Component-Level Design
Presentation transcript:

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

OHTO -99 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

OHTO -99 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)

OHTO -99 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

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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.

OHTO -99 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,…

OHTO -99 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.

OHTO -99 HUMAN INTERFACE DESIGN Specify human interface functionalities Perform graphical design

OHTO -99 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.

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