Objectives Introduction • Appreciate Software Engineering: –Build complex software systems in the Chapter 1 context of frequent change • Understand how to –produce a high quality software system within the allowed time –deal with complexity and change as the system is developed • Acquire technical knowledge Software Engineering: Acquire Technical Knowledge A Problem Solving Activity • Understand System Modeling • Learn UML (Unified Modeling Language) • Analysis : Understand the nature • Learn different modeling methods: of the problem and break the • Use Case modeling problem into pieces • Object Modeling • Dynamic Modeling • Issue Modeling • Learn how to use Tools: • Synthesis : Put the pieces together – CASE (Computer Aided Software Engineering) into a large structure • Component-Based Software Engineering – Learn how to use Design Patterns and Frameworks Software Engineering: Software Engineering: Definition A Problem Solving Activity For problem solving we use Software Engineering is a collection of techniques, methodologies and tools that • Techniques (methods): – Formal procedures for producing results using help with the production of some well-defined notation • Methodologies: • a high quality software system – Collection of techniques applied across software development and unified by a • with a given budget philosophical approach • before a given deadline • Tools: – Instrument or automated systems to accomplish a technique while change occurs. 1
Dealing with Complexity Factors affecting the quality of a software system • Complexity: 1. Abstraction – Most systems are so complex that no single programmer can understand an entire system – The introduction of one “bug fix” causes another bug 2. Decomposition • Change: 3. Hierarchy – The “Entropy” of a software system increases with each change: Each implemented change erodes the structure of the system which makes the next change even more expensive (“Second Law of Software Dynamics”). – As time goes on, the cost to implement a change will be too high, and the system will then be unable to support its intended task. This is true of all systems, independent of their application domain or technological base. 1. Abstraction Exercise 1 – Problem 1 • Discuss the 7 ± 2 short term • Inherent human limitation to deal with complexity memory limitation as applied to remembering phone numbers –The 7 +- 2 phenomena • Chunking: Group collection of • How does “chunking” help you remember longer phone numbers? objects • Ignore unessential details: => Models Models are used to provide abstractions Models are used to provide abstractions • System Model: • Task Model: – PERT Chart: What are the dependencies –Object Model: What is the structure of between the tasks? the system? What are the objects and how are they related? – Schedule: How can this be done within the time limit? –Functional model: What are the – Org Chart: What are the roles in the project or functions of the system? How is data organization? flowing through the system? • Issues Model: –Dynamic model: How does the system react to external events? How is the – What are the open and closed issues? What constraints were posed by the client? What event flow in the system ? resolutions were made? 2
Example of an Issue: Galileo vs the Church Interdependencies of the Models • What is the center of the Universe? System Model (Structure, –Church: The earth is the center of the Functionality, universe. Why? Aristotle says so. Dynamic Behavior) –Galileo: The sun is the center of the universe. Why? Copernicus says so. Also, the Jupiter’s moons rotate around Jupiter, not around Earth. Issue Model Task Model (Proposals, (Organization, • Resolution (1998): The church Arguments, Activities declares the earth is not the center Resolutions) Schedule) of the universe Exercise 1 – Problem 2 2. Decomposition • A technique used to master complexity (“divide • Issue : select a data structure for a and conquer”) priority queue given three choices: • Functional decomposition unordered list, ordered list, and – The system is decomposed into modules heap assuming equal number of – Each module is a major processing step (function) in the application domain insertions and deletions. – Modules can be decomposed into smaller modules • Evaluate each choice by giving • Object-oriented decomposition advantages and disadvantages for – The system is decomposed into classes (“objects”) – Each class is a major abstraction in the application each and then justify your final domain selection for the priority queue. – Classes can be decomposed into smaller classes • Class identification is crucial to Functional Decomposition object-oriented modeling • Functionality is spread all over the system • Basic assumption: • Maintainer must understand the whole 1.We can find the classes for a new system to make a single change software system: We call this • Consequence: Greenfield Engineering –Code is hard to understand 2.We can identify the classes in an –Code is complex and “impossible” to existing system: We call this maintain Reengineering –The user interface is awkward and non- 3.We can create a class-based interface intuitive to any system: We call this Interface Engineering 3
3. Hierarchy Part of Computer Hierarchy • Another way to deal with complexity is to provide simple relationships between the chunks CPU Memory I/O Devices • One of the most important relationships is hierarchy • Two important hierarchies –"Part of" hierarchy ALU Program Cache Counter –"Is-kind-of" hierarchy Is-Kind-of Hierarchy (Taxonomy) Software Lifecycle Definition • Software lifecycle: Cell – Set of activities and their relationships to each other to support the development of a software system • Typical Lifecycle questions: Nerve Blood Muscle Cell Cell Cell – Which activities should I select for the software project? – What are the dependencies between activities? Smooth Striate Pyramidal Cortical Red White – How should I schedule the activities? Reusability Software Lifecycle Activities • A good software design solves a specific problem but is general enough to address future problems (for example, System Object Implemen- changing requirements) Requirements Analysis Testing Design Design tation Elicitation • Experts do not solve every problem from first principles . They reuse solutions that Solution Application Source Use Case Sub- Test have worked for them in the past Domain Domain Code Model systems Cases Objects Objects • Goal for the software engineer : Design the software to be reusable across application domains and designs • How? Use design patterns and frameworks whenever possible 4
Design Patterns and Frameworks Patterns are used by many people • Design Pattern: • Chess Master: – A small set of classes that provide a template solution – Openings to a recurring design problem – Middle games – Reusable design knowledge on a higher level than – End games data structures such as linked lists, binary trees, etc. • Writer • Framework: – Tragically Flawed Hero (Macbeth, Hamlet) – A moderately large set of classes that collaborate to – Romantic Novel carry out a set of responsibilities in an application – User Manual – Examples: User Interface Builder • Architect • Provide architectural guidance during the design – Office Building phase – Commercial Building • Provide a foundation for the software components – Private Home industry Summary Patterns are used by Software Engineers • Software engineering is a problem solving activity –Composite Pattern: A collection of – Developing quality software for a complex problem objects needs to be treated like a within a limited time while things are changing single object • There are many ways to deal with complexity –Adapter Pattern (Wrapper): Interface – Modeling, decomposition, abstraction, hierarchy – Issue models: Show the negotiation aspects to an existing system – System models: Show the technical aspects –Bridge Pattern: Interface to an – Task models: Show the project management aspects existing system, but allow it to be – Use Patterns and Frameworks: Reduce complexity extensible even further 5
Recommend
More recommend
