Software Modeling and Analysis Chapter 1

Software Modeling and Analysis (CS 284)

• Course offered by the College of Science and Computer Engineering at Taibah University, Yanbu, Saudi Arabia
• Instructor: Dr. Musab Kasim Alqudah
• Textbook: Object-Oriented Software Engineering: Using UML, Patterns, and Java, by Bernd Bruegge & Allen H. Dutoit

Chapter 1: Introduction

• Requirements for the class: Students are proficient in a programming language but lack experience in system analysis and design. Students want to learn the technical aspects of analyzing and designing complex software systems.

Objectives of the Class

• Appreciate Software Engineering: Students will learn to build complex software systems, even in contexts with frequent change and time constraints.
• Build high-quality software systems within a given time frame, while handling complexity and change.
• Technical Knowledge: Students will learn technical knowledge about software systems.
• Managerial Knowledge: The course will cover the software life cycle, both in terms of process and product. Different software lifecycles will be explored, such as Greenfield Engineering (starting from scratch) and Interface Engineering (a type of re-engineering for legacy systems) including practices similar to those discussed in Re-Engineering (Hammer & Champy, 1993).

Acquire Technical Knowledge

• System Modeling: Develop an understanding of System Modeling. The Unified Modeling Language (UML) will be used heavily in the class.
• UML: The course will focus on approximately 20% of aspects of UML.
• Software Lifecycle Phases: The course covers modeling at various software life cycle stages, including Requirements Elicitation (Chapter 4), Analysis (Chapter 5), Architectural Design (Chapters 6 & 7), Object/Component Design (Chapter 8), Coding (Chapter 10), and Testing (Chapter 11). Delivery items in this order are also deliverables 1–6.
• Deliverables: The course has different deliverables (1–6) that are part of the course. Some of them will be done during a demo.
• Traceability Among Models: The technique of tracing among models will be a focus.
• CASE Tools such as Rational Rose are to be covered as part of the course.

Readings

• Required: Bernd Bruegge, Allen Dutoit - "Object-Oriented Software Engineering: Using UML, Patterns, and Java"
• Recommended:
  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, by C. Larman
  • Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
  • The Unified Modeling Language User Guide, by Grady Booch, James Rumbaugh, and Ivar Jacobson
  • "Objective Knowledge, an Evolutionary Approach," by K. Popper
• Additional readings: May be provided in individual lectures.

Why Software Engineering?:

• Standish Report highlighted the issue with software projects totaling $96.7 million and issues around delivering software within budget and timelines.
• The report (the “Chaos” report) showed a significant percentage of software projects: Were delivered but were not successfully used (45%); were paid for, but not delivered (30%); were used as delivered but were only usable with extensive rework (3%); or used with extensive rework but later abandoned (20%).

Characteristics of Software Systems

• Complex Creations: Software systems involve extensive functions and often conflicting objectives, many components, and people from diverse disciplines, and development cycles that span years.
• Constant Changes: Clients and users often change their requirements, discovering errors during the process, and developers gaining new understanding, along with technological changes and staff turnover. Software systems are affected by these changes as well.

Software Engineering: A Problem-Solving Activity

• Analysis: Understanding the problem's nature and dividing it into smaller components.
• Synthesis: Bringing the problem's components back into a large system or whole.
• Techniques: Formal procedures and notations used for creating outcomes based on defined standards.
• Methodologies: A collection of techniques united by a philosophical or principles approach.
• Tools: Instruments and automated tools or systems that help use the techniques.

Software Engineering: Definition

• A discipline for producing quality software meeting given budget and deadline constraints, while accommodating changes.

Scientist vs. Engineer

• Computer Scientist: Focuses on theoretical aspects like algorithms and representation schemes. Generally, they have infinite time to work on these concepts.
• Software Engineer: Addresses practical solutions and employs tools and techniques for clients or customers. There is generally a time constraint on solving these problems.

Factors Affecting Software System Quality

• Complexity: No single programmer can fully grasp the entire system. Introduction of a fix can cause new problems.
• Change: Entropy increases with every modification, creating dependencies which make future modifications more expensive. Over time, the cost of implementing changes can become prohibitive, making the system unable to meet its intended purpose in a timely manner. This is true regardless of application domain or technology.

Model-based Software Engineering

• Code is a derivation of the object model: A systematic approach to developing software where code is directly derived from a design model.

Example of an Issue: Galileo vs the Church

• Different perspectives and authorities on the center of the universe, illustrating conflicting models of understanding and resolving an issue.

Issue Modeling

• The modeling of an issue, how the issue is presented and potentially resolved, how disagreements can arise and perspectives may differ and the importance of modeling issues in software development.

Dealing with Complexity: Abstraction, Decomposition, and Hierarchy

• Abstraction: Focusing on essential features and ignoring details irrelevant to the current concern.
• Decomposition: Breaking down complex tasks or systems into smaller, manageable modules.
• Hierarchy: Organizing modules or components in a hierarchical structure to reveal relationships or relationships.

Functional Decomposition

• Functional Decomposition: A method for mastering complexities. Breaking down a system or application into smaller modules according to functional steps or procedures. The level 1 and level 2 decomposition diagram shows that the process occurs and can further be expanded to more detailed steps, which is the functional decomposition in a diagrammatic representation form.
• Functional Decomposition - Consequences: Functionality is scattered in the system; maintainers need an understanding of the whole to make changes. This leads to hard-to-understand and hard-to-maintain code, often awkward user interfaces. Specific examples with regard to functionality, like Microsoft PowerPoint's Autoshapes, were discussed. Microsoft's approach to Autoshapes is considered a good use case for understanding how functional decomposition can result in scattered code.

OO-Decomposition: Class Identification

• Identifying Classes: A critical aspect. Methodologies for approaching both new and existing systems were covered. The concept of Greenfield and Reengineering were discussed. Philosophies (science, experimentation, and evidence) can support these engineering practices when approaching problems.
• Limitations: Depending on the system's purpose, different classes can emerge. A systems purpose is important to class identification.

Model of an Eskimo

• An example to illustrate the object model, its elements and considerations for how it should be designed.

Iterative Modeling

• Iterative approach to modeling and design: Iterative modeling involves multiple iterations in the software development process to accommodate changes as those changes are encountered. A change in model may lead to modification in another model (iteration). The concept of Iterative Modeling and design were covered in some detail.

Many Ways to Deal with Change

• The best approach to addressing changes in various aspects of the system are to tailor the software lifecycle to the changing conditions. This includes changing from a linear to a nonlinear method for the lifecycle of the project.

Software Lifecycle Definition

• A lifecycle describes a set of activities and their inherent relationships to support software development. Topics include defining which activities are crucial for a project, the dependencies between activities, and how best to schedule the defined activities.

Software Lifecycle Activities

• The activities of developing a software system (requirements elicitation, analysis, design, implementation, and testing). These stages can be considered as deliverables in the process. Use cases and application domain models should support these stages.

Reusability (Design Patterns and Frameworks)

• Design Patterns: Reusable solutions for common design problems. They go beyond data structures.
• Frameworks: Large sets of classes that provide a structure for application development. Examples include user interface builders.

Summary

• Problem Solving: Software engineering is a problem-solving activity that involves developing high-quality software solutions in a timely manner while dealing with inevitable changes.
• Dealing with Complexity: Various methods are available to address complexity, including modeling, decomposition, and abstraction.
• Issue, System, and Task Models: Issue models address negotiations and constraints, system models reveal technical details, and task models deal with project management.
• Using Patterns: Design patterns can also be used to help handle complexity.
• Tailoring the Lifecycle: Life cycles need to be adjusted to the dynamic nature of modern projects.
• Nonlinear Approach: Use a nonlinear lifecycle to account for changing requirements and technology.
• Configuration Management: Use configuration management to address the change in entities.

Software Production Poor Track Record (e.g., Space Shuttle)

• The Space Shuttle program illustrates the difficulties of software production, including cost overruns, delays, quality issues, and the existence of substantial errors that are discovered late in the development process.

A Few Examples

• Specific examples illustrating software project problems (e.g., the millennium bug, supermarket fine related to program errors related to leap year considerations, errors in the Denver International Airport's luggage system).

Another Example: Space Shuttle Software

• Software issues like cost overruns, delays, and quality problems existed with the Space Shuttle program.

Reusability

• Good software design can solve problems, generalize the solutions to handle future ones. Experts often reuse previous solutions and designs, thus reuse is important.

Patterns (e.g., Chess Master, Software Engineer)

• Understanding how widely applicable patterns can be useful to various scenarios, such as chess and software engineers.