8 September 2010. Your Architecture First level diagram: how components fit together.

Slides:



Advertisements
Similar presentations
Design Validation CSCI 5801: Software Engineering.
Advertisements

Ch 3 System Development Environment
Key-word Driven Automation Framework Shiva Kumar Soumya Dalvi May 25, 2007.
© AgiliX Agile Development Consulting Agile Software Architecture Cesario Ramos.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
ECHO: NASA’s E os C learing HO use Integrating Access to Data Services Michael Burnett Blueprint Technologies, 7799 Leesburg.
8 September Announcements  GIT Class: Friday 3-5 SN 115 (Peter Parente)  Information for Project Links PageProject Links Page  Hot Topics Teams.
© Prentice Hall CHAPTER 9 Application Development by Information Systems Professionals.
THE OBJECT-ORIENTED DESIGN WORKFLOW Interfaces & Subsystems.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Patterns Design 13 February.
Design 15 February. Software Engineering: Elaborated Steps Concept (contract, intro on web site) Requirements (use cases, requirements) Architecture Design.
Developed by Reneta Barneva, SUNY Fredonia Component Level Design.
Systems Design. Analysis involves understanding and documenting user requirements in a clear and unambiguous way. It focuses on the business side and.
Course Instructor: Aisha Azeem
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 17 Software Quality
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 17 Software Quality
© UNT in partnership with TEA1 7 th Grade Career Exploration Module Career Focus: Video Game Programmer Occupation.
The Design Discipline.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Engineering Design Resolution & Design Principles.
Managing Software Quality
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Pertemuan 5 Pengembangan Teknologi Informasi Matakuliah: H0402/PENGELOLAAN SISTEM KOMPUTER Tahun: 2005 Versi: 1/0.
Requirement Analysis Functional & Non-Functional Requirements Scenarios Use cases: – View Fixtures – Manage Tournament – Register Team – Report Discrepancy.
3 September Engineering  Turning ideas into reality  Creating something useful from other things using science and math.
Software Engineering Chapter 8 Fall Analysis Extension of use cases, use cases are converted into a more formal description of the system.Extension.
Ceg860 (Prasad)L6MR1 Modularity Extendibility Reusability.
Supplementary Specifications (Chapters 20,22 - Requirements Text) 1.
E MBEDDED S YSTEMS S OFTWARE T RAINING C ENTER S OFTWARE D ESIGN C OPYRIGHT © 2011 DSR C ORPORATION.
COMP 354 Software Engineering I Section BB Summer 2009 Dr Greg Butler
University of Toronto Department of Computer Science CSC444 Lec05- 1 Lecture 5: Decomposition and Abstraction Decomposition When to decompose Identifying.
System Models, Patterns and Software Architectures 14 February.
EAST-ADL Domain-Model – Overview and Planning – Mark-Oliver Reiser (TUB) AMST Workshop Berlin,
Principles and Techniques of Evolutionary Architecture Rebecca Parsons Chief Technology Officer ThoughtWorks.
June 05 David A. Gaitros Jean Muhammad Introduction to OOD and UML Dr. Jean Muhammad.
Enabling Project Communication, Collaboration & Workflow (CCW)
Jan. 29, 2002Grand Challenges in Simulation Issues in Enhancing Model Reuse C. Michael Overstreet Richard E. Nance Osman Balci.
Team Think For You. Outline  Introduction  Process  Requirements Engineering  Architecture  Detailed Design  Testing  Demo  Extensibility  Conclusions.
Chapter 7 Software Engineering Introduction to CS 1 st Semester, 2015 Sanghyun Park.
CBSE 2014 Modeling Components with UML. Bibliography Modelling components in UML – Main text: Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly,
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
1 CMPT 275 High Level Design Phase Modularization.
1 Venkat Subramaniam Quality of Software Design Good design is critical to a software application A good design has following characteristics –Specific.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Evaluating Architectures. Quality Control Rarely fun, but always necessary 1.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
© 2010 John Wiley & Sons Ltd. Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
1 Unified Modeling Language, Version 2.0 Chapter 2.
Design and Planning Or: What’s the next thing we should do for our project?
ANU comp2110 Software Design lecture 8 COMP2110 Software Design in 2004 lecture 8 Software Architecture 1 of 2 (design, lecture 3 of 6) Goal of this small.
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with IBM Rational Software Architect V7.5 Module 17: Team Modeling.
Design. Practices Principles Patterns What are the characteristics of good design? What are good solutions to common design problems? How do we go about.
Chapter 19: Building Systems with Assurance Dr. Wayne Summers Department of Computer Science Columbus State University
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
CaBIG Architecture Working Group Face-To-Face Meeting  Best Practices SIG  March 18th, 2005  David Kane and Jim Harrison.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Team Skill 2 Understanding User and Stakeholder Needs The features of a Product or System (9)
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
BLACKBOARD WIKI TOOL From your Group…. There is a Group Tools menu and from there you select “Group Wiki”
Basic Characteristics of Object-Oriented Systems
Basic Concepts Key Learning Points : The objectives of this chapter are as follows:  To provide an introduction to the basic Concepts of enterprise architectures,
1 Acquisition Automation – Challenges and Pitfalls Breakout Session # E11 Name: Jim Hargrove and Allen Edgar Date: Tuesday, July 31, 2012 Time: 2:30 pm-3:45.
Software Engineering Salihu Ibrahim Dasuki (PhD) CSC102 INTRODUCTION TO COMPUTER SCIENCE.
Software Design.
Basic Concepts in Software Design
Software life cycle models
Software Design Lecture : 14.
Presentation transcript:

8 September 2010

Your Architecture First level diagram: how components fit together

What Architectures Do You Know?

Software Architecture Goals  Extensibility: adding new features Tradeoff of generality and time How might it be extended?  Changeability: requirements changes  Simplicity: ease of understanding and implementing  Efficiency: speed and size

Key Characteristics  Cohesion degree to which communication takes place within the module  Coupling degree to which communication takes place between modules  Min-max problem: minimize coupling while maximizing cohesion

Examples  Role-playing game Decompose into 4 modules: environment, game control, participants and artifacts High cohesion and high coupling ○ When two characters meet, all 4 modules are involved  Personal finance application Decompose into user activities: accounts, bill playing, loans, investments Low cohesion and high coupling ○ Accounts are pretty independent ○ Loan payment would involve the first 3 modules

Key Development Tools  Revision Management System  IDE  Wiki  API Documentation Extraction

Documentation Principles  Need to reflect changes Not just change, but CAPTURE change Version control  Need to keep all documents synchronized Only say it once  Danger of shared ownership: If many own, no one owns  Practical consideration: Responsibility vs. authority