Object Oriented Design. Goals  Levels of abstraction  Workshop: group meeting for Pragmatic Web homework.

Slides:



Advertisements
Similar presentations
Database System Concepts and Architecture
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
OBJECT ORIENTED PROGRAMMING M Taimoor Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Unified Modeling Language
Paul Deitel, CEO Deitel & Associates, Inc.. Contact Information  Paul Deitel, CEO  Deitel & Associates, Inc.  Twitter:  Facebook:
Object-Oriented Analysis and Design
Introduction To System Analysis and Design
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
HAS. Patterns The use of patterns is essentially the reuse of well established good ideas. A pattern is a named well understood good solution to a common.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Itntroduction to UML, page 1 Introduction to UML.
Object Oriented Concepts. Movement toward Objects Instead of data-oriented or process-oriented Analysis, many firms are now moving to object-oriented.
Object-oriented design CS 345 September 20,2002. Unavoidable Complexity Many software systems are very complex: –Many developers –Ongoing lifespan –Large.
Object-Oriented Analysis and Design
The chapter will address the following questions:
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
OO Analysis and Design CMPS OOA/OOD Cursory explanation of OOP emphasizes ▫ Syntax  classes, inheritance, message passing, virtual, static Most.
ICT Management page 1MBA BORM - BORM © - Business Object Relation Modeling Know-How Fund of British Council, ČVUT v Praze, ČZU Praha,
Software Engineering CS B Prof. George Heineman.
Introduction to Object-oriented programming and software development Lecture 1.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Class Project OO Design Document Here is what you need to do for your class.
2-Oct-15 Bojan Orlic, TU/e Informatica, System Architecture and Networking 12-Oct-151 Homework assignment 1 feedback Bojan Orlic Architecture.
CS 360 Lecture 6.  A model is a simplification of reality  We build models to better understand the system being developed.  We build models of complex.
2/6/01D-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Using PARTS to Illustrate Requirements Concepts.
Recap (önemli noktaları yinelemek) from last week Paradigm Kay’s Description Intro to Objects Messages / Interconnections Information Hiding Classes Inheritance.
High-Level Design With Sequence Diagrams COMP314 (based on original slides by Mark Hall)
3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 3, Slide 1 February 20, 2004 Lecture 3: Introduction to Software Analysis and.
Introduction To System Analysis and Design
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
11 Chapter 11 Object-Oriented Databases Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
System models l Abstract descriptions of systems whose requirements are being analysed.
IT 21103/41103 System Analysis & Design. Chapter 05 Object Modeling.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Class Project OO Design Document Here is what you need to do for your class project.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Business Applications with Object-Oriented Paradigm (Modeling Concepts) Professor Chen School of Business Gonzaga University Spokane, WA
CMSC 345 Fall 2000 OO Design. Characteristics of OOD Objects are abstractions of real-world or system entities and manage themselves Objects are independent.
Introduction to Modeling Extracted from textbook: Object Oriented Modeling and Design with UML M. Blaha, J. Rumbaugh.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Class Diagrams. Terms and Concepts A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
OOPS CONCEPT.  OOPS  Benefits of OOPs  OOPs Principles  Class  Object Objectives.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
MANAGING COMPLEXITY Lecture OO01 Introduction to Object-oriented Analysis and Design Abstract Data Types.
SWE 214 (071) Introduction to UML Slide 1 Introduction to UML.
Class Design. Class Design The analysis phase determines what the implementation must do, and the system design.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
 The Object Oriented concepts was evolved for solving complex problems. Object- oriented software development started in the 1980s. Object-oriented design.
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Object Oriented Concepts -I
The Object Oriented Approach to Design
Object-Oriented Design
CS 8532: Advanced Software Engineering
From Use Cases to Implementation
Presentation transcript:

Object Oriented Design

Goals  Levels of abstraction  Workshop: group meeting for Pragmatic Web homework

What is Abstraction?  A design technique that focuses on the essential aspects of an entity and ignores or conceals less important or nonessential aspects. (

What is Abstraction?  Programming in an appropriate level of abstraction means choosing ‘primitives’ that are appropriate for the problem (and to the programmer) at hand.  Separates the programming task into two nearly independent tasks u solving the original problem in terms of “abstract primitives” u dealing with the details of implementing these abstract primitives (Leron, 1987)

What is Abstraction?  What we’ve been doing so far (e.g. in the design of Frogger and Space Invaders)!  A big part of OO design is about abstraction u Creating classes (attributes, operations) and specifying their interactions with other classes  encapsulates functionality in meaningful high-level chunks or groups  abstracts functionality to a higher level where concepts of the problem domain are better understood and communicated

A good abstraction is…  Well named u meanings, intuitions, impressions, and expectations generated by a name accurately reflect the nature of the abstraction  Coherent u contains a related set of attributes and behavior that makes sense from the viewpoint of the modeler  Complete u contains all of the attributes and behavior necessary to manipulate the abstraction for its intended purpose  Accurate & Minimal u does not contain attributes or behavior extraneous to the purpose for which it is defined (

Why Abstraction?  Crucial for creating tractable software because the real-world objects are too complex to be captured and understood in complete detail  Creates a higher conceptual level that u hides implementation details u is closer to human cognition, how we think about a problem  => Promotes understanding and affords communication

Levels of Abstraction  Semantic Level  Syntactic Level  Machine Level Generation Specification Implementation

Specification Level: UML Sequence Diagram die () X [see shrimp] octopus:animal Generation Specification Implementation shrimp:animal try-to-eat ()

Implementation Level: VAT Generation Specification Implementation

Generation Level: Java Byte Code generated by Ristretto ® Generation Specification Implementation

Specification Level for AgentSheets  Behavior Wizard  Specification tool at the level of UML specifically for AgentSheets u Specify agent classes from predefined types u Specify behavior at a high level  Generates behaviors at the implementation level (VAT) Generation Specification Implementation

Specification for End- Users  Specify agent classes from predefined types

Specification for End-Users  Specify behavior at a high level  Implementation for End-Users  High-level programming provides customized support for particular applications

Generation for End-Users  Generates behaviors at the lower-level of implementation (VAT)

Meta-Specification: creating templates  Different aggregations of underlying behaviors  Different points of user control (parameters)  Overlapping or disjoint

Issues  Conceptual u Finding the right level of abstraction  For EUP, knowing who the user is, is especially important u Deciding what to show, what to hide, how much detail, what should be visible to the user, what aspects of the behavior should be controllable by the user  Technical u Providing the mapping from the specification to the implementation level

Homework 4  Choose a name for your team.  Design the project AS A TEAM. Use any design methods/diagrams you find useful as a means to organize your work and communicate as a team.  Implement the project in AgentSheets AS A TEAM. You are responsible for finding meaningful ways to divide workload within your team.  ONE member of your team should turn in (via ): u Team name and members u Design diagrams u AgentSheets Project folder (zipped or stuffed): Please follow naming conventions (use your team's name) u Description of your project including directions on how to use it. Please include any insights on pragmatic web applications, accessing data, utilizing it in a simulation, and presenting it to the user.  Due: Oct. 1

Reading Assignment  Download “ComponentWare” article from class web site and read it before you come to class on Thursday 9/26.  We will use it as a basis for a class discussion on objects, components and reuse. u Reminder: class participation counts towards your grade  Due: Sept. 26

Workshop  If you do not have a group, join an existing one or form new ones with other “groupless” classmates  Meet with your group u Design project u Divide workload among group members