Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Stephen Herbert Daniel Coming Ogechi Ugwulebo James King Jigna J. Bhatt Casey J. Powell.

Slides:



Advertisements
Similar presentations
Performance Testing - Kanwalpreet Singh.
Advertisements

A Brief Introduction. Acknowledgements  The material in this tutorial is based in part on: Concurrency: State Models & Java Programming, by Jeff Magee.
Object-Oriented Analysis and Design
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 04. Other.
Informatics 43 – May 7, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases  No.
2 Object-Oriented Analysis and Design with the Unified Process Objectives  Explain how statecharts can be used to describe system behaviors  Use statecharts.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Computer ScienceSoftware Engineering Slide 1 Team l Team Leads: Put your list of questions for Galaxy Sleuth on your web page and send me the URL l Everyone:
Computer ScienceSoftware Engineering Slide 1 Review l The need for software engineering l Processes Waterfall Iterative waterfall Evolutionary Formal systems.
Chapter 13 Physical Architecture Layer Design
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
Quiz What activities are part of a software development process?
Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Andrew Rodgers Daniel Coming Ogechi Ugwulebo William Nelson Jigna J. Bhatt Casey J.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Teamwork Know each other Compete Leadership Strengths and Weaknesses
Chapter 4 Product Design. Objectives of Design  As all other aspects of object-oriented system development, design can be deployed in an iterative or.
Chapter 4 Database Management Systems. Chapter 4Slide 2 What is a Database Management System (DBMS)?  Database An organized collection of related data.
Chapter 3 Object-Oriented Analysis of Library Management System(LMS)
Chapter 7: The Object-Oriented Approach to Requirements
Architectural Design.
Chapter 10 Architectural Design
The Design Discipline.
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
UML - Development Process 1 Software Development Process Using UML (2)
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
Quality Attributes of Web Software Applications – Jeff Offutt By Julia Erdman SE 510 October 8, 2003.
Product Design Phases. Design Structured Walk-Through marks the end of the Analysis phase and the beginning of the Design phase –Recall the Structure.
An Introduction to Software Architecture
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 13: Physical Architecture Layer Design Alan Dennis,
Lecture 9: Chapter 9 Architectural Design
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Chapter 11 Analysis Concepts and Principles
Computer ScienceSoftware Engineering Slide 1 Today l As3 grading Clarity, completeness, inconsistencies Comments l CVS guru name l Project assignment l.
Approaching a Problem Where do we start? How do we proceed?
Lecture 3 Uses Cases Topics UML Use Cases pop quiz Readings: Chapter 3 January 24, 2008 CSCE 492 Software Engineering.
UML diagrams What is UML UML diagrams –Static modeoing –Dynamic modeling 1.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
Accelerating Java Development with the UML Greg Schottland General Manager, Application Development Tools Embarcadero Technologies,Inc.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
Documenting Software Architectures 1.Uses and Audiences for Architecture Documentation Architecture documentation serves as a means of education Architecture.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Computer ScienceSoftware Engineering Slide 1 CS425/CS625 l List of classes for the banking system l Groups for projects l Software development process.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
DISTRIBUTED COMPUTING. Computing? Computing is usually defined as the activity of using and improving computer technology, computer hardware and software.
Course Instructor: Kashif Ihsan 1. Chapter # 3 2.
Construction Planning and Prerequisite
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
12 Chapter 12: Advanced Topics in Object-Oriented Design Systems Analysis and Design in a Changing World, 3 rd Edition.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
1 Lecture 3 Major Architectural Models View (Cont’d) Architectural Models/Patterns Architecture Case Study Software Architecture & Design Pattern.
Web-based Front End for Kraken Jing Ai Jingfei Kong Yinghua Hu.
4+1 View Model of Software Architecture
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
Introduction to UML and Rational Rose UML - Unified Modeling Language Rational Rose 98 - a GUI tool to systematically develop software through the following.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
UML Diagrams By Daniel Damaris Novarianto S..
Software Design and Architecture
Systems Analysis and Design With UML 2
Object-Oriented Analysis
Presentation transcript:

Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Stephen Herbert Daniel Coming Ogechi Ugwulebo James King Jigna J. Bhatt Casey J. Powell Brett Harrison Jonathan Ward Michael Vidal Don Miller James Frye David Brewer Olja Mihic Casey Mees Maggie Lu Reid Webber Taisuke Nagayama Jeff Payne Matasaka Sako Howard C. Wu Shana Rheault RichardD.VanHorn Rodel Mangoba Steve Luong Jason Dodd Beifang Yi Dorothy P. Cheung William Nelson Will Woolsey Andrew Rodgers James Cohen, Judy Rowley, Stan Sexton, Rajashekhar Yakkali, Kazuhito Mori

Computer ScienceSoftware Engineering Slide 2 Project Management tools l See the projects web page l Concurrent Versions System (CVS) l Coding standards Java coding standard document

Computer ScienceSoftware Engineering Slide 3 What have we learned so far? l Murphy's Technology Laws 1. Logic is a systematic method of coming to the wrong conclusion with confidence. 2. Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition. 3. Nothing ever gets built on schedule or within budget. 4. All's well that ends. 5. Any given program, when running, is obsolete. 6. To spot the expert, pick the one who predicts the job will take the longest and cost the most.

Computer ScienceSoftware Engineering Slide 4 What have we learned so far? l The first step in software development is understanding the system to be developed l This is requirements analysis l Requirements analysis starts with a description of the system l The description is refined into a requirements document

Computer ScienceSoftware Engineering Slide 5 Requirements document l Interaction between engineering, marketing and clients (domain experts) l Iterative l Increase understanding of system Informal scenarios help understanding and appreciation of system complexity Raise questions that need to be answered by domain experts Propose GUI/UI (more on GUI design later) l Requirements document (formatted formal document)

Computer ScienceSoftware Engineering Slide 6 Do you understand system? l Validate your understanding l Use Case Centered Design (UCCD) Scenarios Comprehensive, explore all interaction with system UML class diagrams Initial design List of primary classes (nouns, properties of primary classes) UML use-case diagrams Compact representation of use of system

Computer ScienceSoftware Engineering Slide 7 Next? l Troutman's Laws of Computer Programming 1. Any running program is obsolete. 2. Any planned program costs more and takes longer. 3. Any useful program will have to be changed. 4. Any useless program will have to be documented. 5. The size of a program expands to fill all available memory. 6. The complexity of a program grows until it exceeds the capability of its maintainers. 7. Any system that relies on computer reliability is unreliable. 8. Any system that relies on human reliability is unreliable. 9. Make it possible for programmers to write programs in English, and you will find that programmers cannot write in English. 10. Profanity is the one language all programmers know best.

Computer ScienceSoftware Engineering Slide 8 Next l Persistence? l Inter-process communication? l HCI l Architecture Grouping primary classes Interfaces l Design l Implementation l Validation

Computer ScienceSoftware Engineering Slide 9 Persistence l LMS l Galaxy sleuth l GPA

Computer ScienceSoftware Engineering Slide 10 Object Persistence l Object persistence seeks to retain object information on some persistent storage medium as a file or through a DBMS l Object serialization works for situations where all object information can reside in memory at once l Because most commercial DBMSs are relational in contrast to object-oriented, some translation between the object and relational representations must be made

Computer ScienceSoftware Engineering Slide 11 Evaluating Object Persistence l Security Hacker proof Allows reconstruction in face of malicious use l Information growth Solution still works with increased data volume l Concurrency Concurrency solution allows for increased users

Computer ScienceSoftware Engineering Slide 12 LMS: Object Persistence l LMS may contain hundreds of thousands of book entries as well as thousands of other library resources l such a volume of data does not permit object streaming l A DBMS is called for to provide Concurrent access by multiple users Security enforcement of different access levels for various user categories Allow for increased data capacity

Computer ScienceSoftware Engineering Slide 13 What do we want to persist? l System state ?

Computer ScienceSoftware Engineering Slide 14 LMS Case Study: Relational Representation of Data Relational TablesBook Resource List Patron Address Patron

Computer ScienceSoftware Engineering Slide 15 Process Architecture l Software systems may consistent of processes interacting over a network l Process architecture lays out the machines (nodes) that will host the processes making up the system l Process architecture determines the behavior of the distributed processes l Deployment diagrams are used to model distributed processes

Computer ScienceSoftware Engineering Slide 16 Sample Deployment Diagram Game Client Game Server Internet

Computer ScienceSoftware Engineering Slide 17 Modeling Interprocess Communication l Deployment diagrams show the distribution of process over multiple nodes but do not indicate how these processes communicate l State machines may be used to model communication between processes l The idea behind using state machines for modeling interprocess communication is that the system enters a new state when messages are exchanged between processes

Computer ScienceSoftware Engineering Slide 18 UML Notation for State Machines State Name Intermediate State Initial State Final State Trigger State transition with event trigger State Name State with substates

Computer ScienceSoftware Engineering Slide 19 Sample State Machine Showing Interprocess Communication Player Joining Game Get player name Select token { Client States} { Server State} Communicate remaining tokens player name available tokens selected token

Computer ScienceSoftware Engineering Slide 20 Modeling Multiple Threads of Control l Classes that consist of a separate thread of control are modeled as active classes l Active classes are rendered with thick rectangles as shown below Active class Regular class

Computer ScienceSoftware Engineering Slide 21 Galaxy Sleuth l galaxySleuthServer l gameBoard l playerListener

Computer ScienceSoftware Engineering Slide 22 Design Summary l Create solution for object persistence l Develop user interface designs l Determine process architecture

Computer ScienceSoftware Engineering Slide 23 Possible Obstacles to Effective Meetings l Poor agendas l Dysfunctional communication during the meeting (silence or domination) l Not adhering to the agenda l Discussion may not sufficiently focus on meeting objectives specified by the agenda l Team members are not listening to each other during discussion