Module 16: Physical Design Rationalization. Objectives At the end of this module, you will be able to Understand project and organizational priorities.

Slides:



Advertisements
Similar presentations
Logical and Physical Design of an Information System
Advertisements

Andrea Maurino Web Service Design Methodology Batini, De Paoli, Maurino, Grega, Comerio WP2-WP3 Roma 24/11/2005.
3 Copyright © 2005, Oracle. All rights reserved. Designing J2EE Applications.
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Introduction to Requirements Analysis.
Chapter 10: The Traditional Approach to Design
10-1 © Prentice Hall, 2004 Chapter 10: Selecting the Best Alternative Design Strategy Plus Project Management Concepts.
Systems Analysis and Design in a Changing World, Fifth Edition
S Y S T E M S E N G I N E E R I N G.
Kellan Hilscher. Definition Different perspectives on the components, behavioral specifications, and interactions that make up a software system Importance.
Lecture # 2 : Process Models
Information Systems Analysis and Design
Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
© 2006 Carnegie Mellon University Establishing a Network Centric Capability: Implications for Acquisition and Engineering Dennis Smith Complex System Symposium.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software Process Activities. Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities.
Enterprise Architecture
The Design Discipline.
Software Engineering 1 The Life Cicle of Software Lesson 5.
Systems Analysis and Design in a Changing World, Fifth Edition
CSI315 Web Applications and Technology Overview of Systems Development (342)
RUP Fundamentals - Instructor Notes
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Detailed Design Overview and Mid-Level Class Modeling.
Rational Unified Process Fundamentals Module 4: Disciplines II.
An Introduction to Software Architecture
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
RUP Design RUP Artifacts and Deliverables
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Lecture 7: Requirements Engineering
Systems Analysis and Design in a Changing World, 3rd Edition
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Service Oriented Architecture (SOA) Dennis Schwarz November 21, 2008.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Design Analysis builds a logical model that delivers the functionality. Design fully specifies how this functionality will be delivered. Design looks from.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
Software Design: Principles, Process, and Concepts Getting Started with Design.
10-1 © Prentice Hall, 2004 Chapter 10: Selecting the Best Alternative Design Strategy Object-Oriented Systems Analysis and Design Joey F. George, Dinesh.
® IBM Software Group © 2004 IBM Corporation Developing an SOA with RUP and UML 2.0 Giles Davies.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
CIS 210 Systems Analysis and Development Week 6 Part I Structuring Systems Data Requirements,
8-1 © Prentice Hall, 2007 Topic 8: Selecting the Best Alternative Design Strategy Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra,
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with the IBM Rational Software Architect, V7.5 Module 15: Traceability and Static Analysis.
Chapter 1 Revealed Distributed Objects Design Concepts CSLA.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 15. Review Interaction-Oriented Software Architectures – MVC.
Basic Concepts and Definitions
Chapter : 9 Architectural Design
4+1 View Model of Software Architecture
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
CI R1 LCO Review Panel Preliminary Report. General Comments –Provide clear definition of the goals of the phase (e.g. inception), the scope, etc. in order.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
Gerhard Dueck -- CS3013Architecture 1 Architecture-Centric Process  There is more to software development then going blindly through the workflows driven.
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
11 Systems Analysis and Design in a Changing World, Fifth Edition.
CS 389 – Software Engineering
Software Process Activities.
Lecture 9- Design Concepts and Principles
OO Methodology OO Architecture.
Information Technology Project Management – Fifth Edition
Distribution and components
INFS 6225 Object-Oriented Systems Analysis & Design
Chapter 2 – Software Processes
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
An Introduction to Software Architecture
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Chapter 6: Architectural Design
Presentation transcript:

Module 16: Physical Design Rationalization

Objectives At the end of this module, you will be able to Understand project and organizational priorities for component packaging and distribution Transform objects into services-based components using the logical design Distribute and package components across the n tiers of the application Use strategy and prototypes to refine packaging and distribution

Lessons 1. Determining a Component Packaging and Distribution Strategy 2. Transforming Objects into Services-Based Components 3. Distributing Components Across Topologies 4. Refining Packaging and Distribution

Lesson 1: Determining a Component Packaging and Distribution Strategy Understanding project and organizational priorities for packaging and distribution

Determining Packaging and Distribution Consider packaging rationales Service category Scalability Performance Manageability Reuse Business context Granularity Align with programming model Example: Stateless and scalable Determine the design trade-offs that impact strategy based on rationales

Reuse and Component Granularity At what level do you get maximum reuse and granularity? Component Granularity Potential for Reuse High LargeSmall Low Within each development environment is an optimum component size that maximizes return on reuse

As a class: 15 minutes Activity Activity 11: Considering Design Factors and Trade-offs Use a hotel property management system as a basis What types of factors and trade-offs would you consider for a component packaging and distribution strategy?

Lesson 2: Transforming Objects into Services-Based Components Transforming objects into services-based components using the logical design

Defining Candidate Components Remember that the focus of rationalization is distributing services among components Use candidate components to provide a bridge between logical objects and service distribution Derive candidate components from the logical object model by iterating through the packaging rationales Make the first cut at components by using the category-of-service rationale

Business Services User Services Data Services User Component Business Component Data Component A B C D Preliminary Components Objects A BC D Moving from Logical to Physical Design

Lesson 3: Distributing Components Across Topologies Distributing and packaging components across the n tiers of the application

Defining a Preliminary Distribution Define components based on category of service and then align them with the proposed component topology Match services to logical tiers to create a distribution baseline Validate and use the other rationales in the packaging strategy to evolve the distribution of services

Distributing Candidate Components User and Business Services Data and Business Services Business Services Validatecustomer Customer Update customer Get customer Replicate customer Customer Archivecustomer Retrievecustomer Assignroom Invoice customer Findcustomer Displaycustomer Customer Preliminary Component Distribution

Lab Lab 7: Distributing Services to Create Candidate Components Use your services and objects from Labs 3 and 4 Refer to the Service Distribution Template Draft a model for distributing the preliminary components across the service tiers Show work on flip charts In small groups: 30 minutes

Lesson 4: Refining Packaging and Distribution Using strategy and prototypes to refine packaging and distribution

Validating Components Think of validation as a fundamental aspect of design, not as a distinct design step Use validation as the trigger for design iteration and evolution Validate against Packaging strategy Design goals Application requirements Logical design Enterprise architecture Prototype, prototype, prototype to evolve the deployment model Possibly update the enterprise architecture

Refining Component Packaging and Distribution Focus on services instead of components Use component/service interaction diagrams to document dependencies Distribute services across component topology as required by packaging rationales Group services into components based on physical location, packaging rationale, and technology constraints Use cohesion and coupling to measure the effectiveness of packaging Address both upward and downward scalability

Cohesion The relationship among different internal elements of a component Receive Payment Component

Coupling The relationship of a component to other components Enter Gift Shop Charges Component Receive Payment Component Check Out Guest Component

Packaging Goal High cohesion Provides a better definition of the components function and behavior Example: Organizing services by business function so that each component has only the services that pertain to its function Loose coupling Provides more flexibility and independence and leads to better defined and simpler interfaces Example: Organizing relationships among components by business function so that each component interfaces with the minimum number of other components for access to data

In small groups: 15 minutes Activity Activity 12: Repackaging and Redistributing Services Use the service distribution from Lab 7 as a basis What is your understanding of techniques for repackaging and redistributing components?

Deliverables of the Rationalization Baseline Task Determining a packaging and distribution strategy Transforming objects into services-based components Distributing components across topologies Using strategy and prototypes to refine packaging and distribution Deliverable Packaging and distribution strategy Services-based components Deployment model Future network topology Future data topology Future component topology Baselined deployment model Rationalization Baseline Rationalization

Summary What are the packaging rationales? What is the focus of physical design rationalization? What is the process for refining component packaging and distribution? What are cohesion and coupling? What are the packaging goals for cohesion and coupling? Summary