object-Oriented Software Engineering Practical Software development using uml and Java Chapter 9: Architecting and Designing Software www.oseng.com
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 9: Architecting and Designing Software
9.1 The Process of design Definition: Design is a problem-solving process whose objective is to find and describe a way To implement the systems functional requirements While respecting the constraints imposed by the non-functional reguirements including the budget -and while adhering to general principles of good quality www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 2 9.1 The Process of Design Definition: • Design is a problem-solving process whose objective is to find and describe a way: —To implement the system’s functional requirements... —While respecting the constraints imposed by the non-functional requirements... - including the budget —And while adhering to general principles of good quality
Design as a series of decisions a designer is faced with a series of design issues These are sub-problems of the overall design problem Each issue normally has several alternative solutions design options The designer makes a design decision to resolve each Issue -This process involves choosing the best option from among the alternatives www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 3 Design as a series of decisions A designer is faced with a series of design issues • These are sub-problems of the overall design problem. • Each issue normally has several alternative solutions: —design options. • The designer makes a design decision to resolve each issue. —This process involves choosing the best option from among the alternatives
Making decisions To make each design decision, the software engineer uses Knowledge of -the requirements -the design as created so far -the technology available software design principles and best practices what has worked well in the past www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software 4
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 4 Making decisions To make each design decision, the software engineer uses: • Knowledge of —the requirements —the design as created so far —the technology available —software design principles and ‘best practices’ —what has worked well in the past
Design space The space of possible designs that could be achieved by choosing different sets of alternatives is often called the design space 上 or example fat-client separate user interface layer for programmed in Java client-server client programmed in Visual Basic thin-client no○ separate programmed in C++ monolithic user interface layer for client www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 5 Design space The space of possible designs that could be achieved by choosing different sets of alternatives is often called the design space • For example: client-server monolithic separate user interface layer for client no separate user interface layer for client fat-client thin-client programmmed in Java programmed in Visual Basic programmed in C++
Component Any piece of software or hardware that has a clear role. a component can be isolated allowing you to replace it with a different component that has equivalent functionality Many components are designed to be reusable Conversely, others perform special-purpose functions www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software 6
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 6 Component Any piece of software or hardware that has a clear role. • A component can be isolated, allowing you to replace it with a different component that has equivalent functionality. • Many components are designed to be reusable. • Conversely, others perform special-purpose functions
Module A component that is defined at the programming language level For example, methods, classes and packages are modules in java www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 7 Module A component that is defined at the programming language level • For example, methods, classes and packages are modules in Java
System A logicalentity, having a set of definable responsibilities or objectives, and consisting of hardware, software or both A system can have a specification which is then implemented by a collection of components A system continues to exist, even if its components are changed or replaced The goal of requirements analysis is to determine the responsibilities of a system Subsystem -a system that is part of a larger system, and which has a definite interface www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software 8
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 8 System A logical entity, having a set of definable responsibilities or objectives, and consisting of hardware, software or both. • A system can have a specification which is then implemented by a collection of components. • A system continues to exist, even if its components are changed or replaced. • The goal of requirements analysis is to determine the responsibilities of a system. • Subsystem: —A system that is part of a larger system, and which has a definite interface
UML diagram of system parts System implementedUsing 1 Component name has res pons ibil ites na me Subsystem Module Framework speci fies interface de fine d at programmm ing lang uage level www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 9 UML diagram of system parts Component name Module defined at programmm ing language level System name has res pons ibilites Subsystem implementedUsing 1..* Framework specifies interface
Top-down and bottom-up design Top-down design First design the very high level structure of the system Then gradually work down to detailed decisions about low-level constructs Finally arrive at detailed decisions such as -the format of particular data items -the individual algorithms that will be used www.oseng.com O Lethbridge/Laganiere 2001 Chapter 9: Architecting and designing software
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 10 Top-down and bottom-up design Top-down design • First design the very high level structure of the system. • Then gradually work down to detailed decisions about low-level constructs. • Finally arrive at detailed decisions such as: —the format of particular data items; —the individual algorithms that will be used