Announcement No CHC visit tomorrow Team progress / issues survey

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Chapter 11 Component-Level Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Object-Oriented Analysis and Design
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
The Architecture Design Process
Lecture 23: Software Architectures
1 CS115 Class 7: Architecture Due today –Requirements –Read Architecture paper pages 1-15 Next Tuesday –Read Practical UML.
Objectives Explain the purpose and objectives of object- oriented design Develop design class diagrams Develop interaction diagrams based on the principles.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
System Architecture: Desing alternatives and methodologies.
Course Instructor: Aisha Azeem
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
1 Architectural Patterns Yasser Ganji Saffar
Object-Oriented Analysis and Design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Architectural Design.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Chapter 10 Architectural Design
The Design Discipline.
Software Waterfall Life Cycle Requirements Construction Design Testing Delivery and Installation Operations and Maintenance Concept Exploration Prototype.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
An Introduction to Software Architecture
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 07. Review Architectural Representation – Using UML – Using ADL.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Systems Analysis and Design in a Changing World, 3rd Edition
Design Concepts and Principles Instructor: Dr. Jerry Gao.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 11 Slide 1 Design.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
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.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
Design Concepts By Deepika Chaudhary.
Dr.Basem Alkazemi
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
1 CMPT 275 High Level Design Phase Modularization.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
Software Design: Principles, Process, and Concepts Getting Started with Design.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
UML / UML 2.0 Diagrams (Part I) 1. Overview of the 13 diagrams of UML Structure diagrams 1.Class diagram 2.Composite structure diagram (*) 3.Component.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Unified Modeling Language, Version 2.0 Chapter 2.
Feb. 9, 2004CS WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004.
Software Engineering B.Tech IT/II Sem-II Term: Unit-4 PPT SLIDES Text Books:1.Software Engineering, A practitioner’s approach Roger s. Pressman.
CHAPTER 3 MODELING COMPONENT-LEVEL DESIGN.
Object and Class Structuring Chapter 9 Part of Analysis Modeling Designing Concurrent, Distributed, and Real-Time Applications with UML Hassan Gomaa (2001)
Basic Characteristics of Object-Oriented Systems
Chapter 14 Software Architecture
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Pertemuan 09 Architectural Patterns Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
Design Engineering 1. Analysis  Design 2 Characteristics of good design 3 The design must implement all of the explicit requirements contained in the.
Design Concepts ch-8
OO Methodology OO Architecture.
Software Quality Engineering
Component-Level Design
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Unified Modeling Language
An Introduction to Software Architecture
Design Yaodong Bi.
Chapter 6: Architectural Design
Software Development Process Using UML Recap
Presentation transcript:

Announcement No CHC visit tomorrow Team progress / issues survey list team members, and attendance today describe progress so far describe intended path into the future describe team problems/issues/questions (technical, team-work related or other)

Design in context Recall SADCITDM Design is the bridge between requirements and code: design comes after software requirements design comes before coding Reading: Section 3.5 and Chapter 5 from Code Complete 2 Notes are from: Software Engineering, A Practitioner’s Approach by Roger Pressman. Software Engineering by Ian Sommerville Code Complete 2 by Steve McConnell

Types of design Architectural design basic structure / major components of system repository model (centralized data storage) client-server model (distributed system) abstract machine model (layered system) control models centralized control (e.g. typical single-threaded application) event-driven decomposition object-oriented models (focus on objects) data-flow models (focus on flow of data and transformation of data as it flows through the system)

Types of design Interface design internal interfaces: interaction amongst components of the system external interfaces: interaction with external systems, devices (producers and consumers of information) user interfaces: interaction with human users

Types of design Component design a component is a “modular building block” a component consists of one or typically more than one module / class a component may already exist (e.g. COTS)

Levels of design Software system Division into subsystems/packages [ARCHITECTURE] Division into classes within packages [COMPONENT & (EXTERNAL) INTERFACE DESIGN] Division into data and routines within classes [CLASS & (INTERNAL) INTERFACE DESIGN] Internal routine design [ALGORITHM DESIGN] Modified from Code Complete 2

Common design principles 1. Abstraction how we deal with complexity (hierarchy of abstractions) procedural abstraction (open, insert) vs. data abstraction (door, collection) Example: structure of US government

Common design principles 1. Abstraction how we deal with complexity (hierarchy of abstractions) procedural abstraction (open, insert) vs. data abstraction (door, collection)

Common design principles 1. Abstraction how we deal with complexity (hierarchy of abstractions) procedural abstraction (open, insert) vs. data abstraction (door, collection)

Common design principles 1. Abstraction how we deal with complexity (hierarchy of abstractions) procedural abstraction (open, insert) vs. data abstraction (door, collection)

Common design principles 2. Architecture overall structure of a software system major components (modules) and their relationships (components exist at different levels of abstraction)

Common design principles 3. Patterns a best-practices solution structure & strategy to a family of problems GOF patterns represent a very small subset of documented patterns

Common design principles 3. Patterns (continued) Architectural patterns – Design patterns – Coding patterns (idioms) Frameworks problem-specific skeletal infrastructure, with hooks for specialized functionality many 115 labs have a simple framework at their core

Common design principles 4. Modularity modules are cohesive components of the overall software system perceived complexity of the combination of two problems P and Q is typically greater than of P and Q taken individually: divide & conquer

Common design principles 5. Information Hiding make capabilities visible to users of a module, but keep algorithms and data structures hidden from users of a module

Common design principles 6. Functional Independence high cohesion (module has a well-defined purpose) low coupling (module has no unnecessary interactions with other modules)

Common design principles 7. Iterative Refinement process of moving from models with high abstraction to models with low abstraction (more concrete)

Common design principles 8. Refactoring functionality preserving improves quality (e.g. increases cohesion, decreases coupling, enhances extensibility, reduces modifiability, etc.) goal of refactoring should be a pattern

Common design principles 9. Design classes: types user-interface classes: abstractions related to user interaction business domain classes: abstractions that model business domain process classes: support/implement business domain classes persistent classes: persistent data storage system classes: manage non-UI external interactions with the system

Common design principles 9. Design classes: characteristics complete & sufficient primitiveness high cohesion low coupling

UML Diagrams (selected) Use Case Diagram Component Diagram Activity Diagram Statechart Diagram Class Diagram Sequence Diagram Deployment Diagram Full UML specification is available at: www.omg.org Material from: OMG UML Spec v1.5 The Object Primer by Scott Ambler

Use Case Diagrams “A use case [represents] a coherent unit of functionality provided by a system” [OMG UML v1.5, p. 3-96] “An actor defines a coherent set of roles that users of an entity can play when interacting with [it]” [OMG UML v1.5, p. 3-97] “Use case diagrams show actors and use cases together with their relationships.” [OMG UML v1.5, p. 3-94]

Component Diagrams “…shows the dependencies among software components…” [OMG UML v1.5, p. 3-169] “A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” [OMG UML v1.5, p. 3-174] “Although a component does not have its own features […] it acts as a container… Components typically expose a set of interfaces, which represent the services provided by the elements that reside on the component.” [OMG UML v1.5, p. 3-170

Activity Diagrams An activity diagram shows logic of a single use case nodes represent activities arcs represent control flow fork/join condition (guard)/decision/merge partitions (swim lanes)

Statechart Diagrams “…describes possible sequences of states and actions through which the element instance [e.g. object] can proceed during its lifetime as a result of reacting to discrete events (for example, signals, operation invocations).” [OMG UMG v1.5, p. 3-135]

Class Diagrams Static structure diagram shows components and relationships

Sequence Diagrams “…model the flow of logic within your system…” “…typically used to model the following: Usage scenarios. […] The logic of methods. […] The logic of services. […]” [Ambler, p. 321]

Deployment Diagrams “…show the configuration of run-time processing elements and the software components…that run on them” [OMG UML v1.5, p. 3-171]

Some Architecture Patterns (www. rationalrose Some Architecture Patterns (www.rationalrose.com/models/architectural_patterns.htm) Broker Model-View-Controller Presentation-Abstraction-Control Microkernel Reflection Layers Pipes and filters Blackboard

Broker pattern “…can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions”

Model-View-Controller (MVC) pattern “…divides an interactive application into three components. The model contains the core functionality and data. View display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model.”

Presentation-Abstraction-Control (PAC) pattern “…defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.”

Microkernel pattern “…applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.”

Reflection pattern “…provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior.”

Layers pattern “…helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.”

Pipes and Filters pattern “…provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems.”

Blackboard pattern “…is useful for problems for which no deterministic solution strategies are known. In Blackboard several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution.”