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