Object-Oriented Analysis & Design Textbook PDF

Textbook: Object-Oriented Analysis & Design Chapter 1 Software Complexity H.S. Sarjoughian CSE 460: Software Analysis and Design School of Computing and Augmented Intelligence Arizona State University, Tempe, AZ, USA...

Textbook: Object-Oriented Analysis & Design Chapter 1 Software Complexity H.S. Sarjoughian CSE 460: Software Analysis and Design School of Computing and Augmented Intelligence Arizona State University, Tempe, AZ, USA Copyright, 2024  A Computer System Abstraction Central Processing Unit (CPU) Clock Central Processing Unit Clock (CPU) Control Unit Control Unit Arithmetic Logic Unit Arithmetic Logic Unit Basic component for a Input Output basic computer Device Device Relationships for a computer system Main Memory Data Flow Control Unit Command / Signal Flow CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 2  Designs for a Basic Computer First Design Second Design CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 3  Composite/Structured Design A method for breaking up a product into modules to achieve Maximal interaction within a module, and Minimal interaction between modules Module cohesion Degree of interactions within a module Module coupling Degree of interactions between modules CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 4  Designs for a Basic Computer (cont.) The two designs are functionally equivalent The second design is Hard to understand Hard to locate faults Difficult to extend or enhance Cannot be reused in another product Modules must be like the first design Maximal relationships within modules, and Minimal relationships between modules CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 5  Discrete Systems Sources of Complexity A very large software has many (hundreds) of thousands of variables can be subjected to many input stimuli (some unpredictable) in a variety of combinations has a huge state-space – numerous possible combinations of values belonging to variables Representations of structure and behavior of a software system are generally not unique Continuous systems have (hidden) order  an essential characteristics that discrete systems should also have. CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 6  Unrestrained Complexity “The more complex the system, the more open it is to total breakdown” Peter, Laurence. Failing to master complexity generally results in a software which: costs far beyond its original estimate is late does not satisfy its stated requirements ⇒ important advances in software engineering have been achieved due to understanding software complexity and what it entails! CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 7  Six Attributes of a Complex System 1. Frequently, complexity takes the form of a hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until some lowest level of elementary components is reached [Hierarchic Structure] 2. The choice of what components in a system are primitive is relatively arbitrary and is largely up to the discretion of the observer of the system [Relative Primitive] 3. Intra-component linkages are generally stronger than inter-component linkages. This fact has the effect of separating the high-frequency dynamics of the components – involving the internal structure of the components – from low-frequency dynamics – involving interaction among components [Separation of Concerns] CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 8  Six Attributes of a Complex System 4. Hierarchic systems are usually composed of only a few different kinds of subsystems in various combinations and arrangements (choice!!) [Common Patterns] 5. A complex system that works is invariably found to have evolved from a simple system that worked …. A complex system designed from scratch never works and cannot be “patched up” to make it work. One has to start over, beginning with a simple working system [Stable Intermediate Forms] 6. Heterogeneity has a direct relationship with a system’s level of complexity [Heterogeneous sub-systems] CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 9  Canonical Form of a Complex Software System Autonomous vehicles Canvas Windows OS Smart manufacturing CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 10  Complexity and Human Cognition Software engineers, like all people, have limitations in handling and dealing with complexity. To handle complexity, we can employ decomposition, software engineers can focus and comprehend a relatively few parts of a complex system, abstraction, software engineers can limit their comprehension by focusing on some information while ignoring a great deal more, and hierarchy, software engineers can view and reason about patterns of structure and behavior for a set of entities. CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 11  Objects, Classes, Models, and Software Engineering Objects and classes are the most elementary elements of object- based software systems. Models are key artifacts capturing a great variety of relationships (structural and behavioral) describing static and dynamic aspects of a software system Generally, a collection of models are required to adequately specify multiple views of a software system There does not exist an automated process that can replace software engineers – at least not yet! Nevertheless, there exist processes and techniques that can bring a significant degree of order and predictability in software development CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 12  Software Products as Compositions of Modules It is impractical to build software product as a single monolithic block of code. coding, testing, debugging, maintenance, reuse, … Dividing the product into parts is necessary. A first definition for module: “A set of one or more contiguous program statements having a name by which other parts of the system can invoke it”, Stevens, Myers, Constantine, 1974 CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 13  Elements of Software Analysis and Design Methods Notation: the language for expressing a family of models Process: The activities leading to a principled construction of models Tools: The artifacts that eliminate the tedium of model building and enforce rules about the models themselves, so that errors and inconsistencies can be exposed and controlled CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 14  Models and Views of Object-Oriented Development dynamic model state transition, … static model logical model class structure, … physical model module architecture, … CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 15  Approach to Component-based Software Engineering Software Specification  Design solutions distilled from Software Architecture successful practice  Techniques for handling high- Software Program Design Patterns level software/system Frameworks, Code design Standards, and Tools  Basic & advanced methods focusing on objects/classes Object-Orientation analysis & design and their relationships CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 16  Engineering with Science and Art Software engineering is a mixture of science and art  Art underlies creativity which generally is key for understanding complex systems  Science provides a rigorous foundation necessary for engineered systems  The mixture of science and art often produces a great many alternative solutions to a given informal problem statement CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 17  Interoperability, Performance, & Reuse (Cont.) Performance: computational local to each component (hardware and software) communication among multiple components (across intranet, internet, …) both computational and communication efficiency issues affect performance Reuse: Component/framework reuse components (e.g., databases) frameworks (e.g., Eclipse Modeling Framework) CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 18  Interoperability, Performance, & Reuse  Complexity refers to the difficulty associated with comprehending multiplicity of interrelated entities. Elements such as composition, heterogeneity, and size are some of the key contributors to software analysis and design complexity. Interoperability: computer-based and non-computer-based subsystems interoperation among many alternative software and hardware components hierarchical construction well-defined functionality & interfacing logical vs. real-time interoperability design, implementation, testing, and operation CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 19  Summary The objective of a software development team is to engineer the illusion of simplicity Software is inherently complex – the complexity of software systems (especially commercial grade) generally exceeds the individual human intellectual capacity Complexity often takes the form of a hierarchy Decomposition, abstraction, and hierarchy are key in handling complexity CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 20  Summary (cont.) Complex systems can be viewed and comprehended by focusing upon objects (things or processes) and their relationships Object-oriented concepts and methods are essential in the development of complex systems – concept development, analysis, design, implementation, …. CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 21  References  Booch, G., et al., Object-Oriented Analysis and Design with Applications, 3rd Edition, Benjamin Cummings, 2007. (OOAD)  Dubberly, Hugh, Models of Models, Interactions Magazine, Vol. XVI.3, 54-60, June, 2009  Martin, R., 2017, Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017  Mathews, van Holde, Ahern, Biochemistry, 3rd Ed., Pearson Benjamin Cummings, 2000. (MvHA)  Peter,L. The Peter Pyramid Or, Will We Ever Get The Point, New York, NY: William Morrow, 1986.  Schach, S., Object-Oriented and Classical Software Engineering, 8th Edition, 2010 CSE 460, ASU, ©H.S. Sarjoughian OOAD : Ch. 1 : Software Complexity 22