csce 431: midterm exam review. outline software engineering software lifecycle requirements...

CSCE 431:Midterm Exam Review

CSCE 431 Midterm Exam Review

Outline

• Software Engineering

• Software Lifecycle

• Requirements

• Configuration Management

• Object Oriented Design

• UML

• Design Patterns


Midterm Exam

• Thu 3/6 12:45-2:00pm

• Covers Introduction through Design Patterns

• Covers Homeworks 1 and 2

• Focus on material covered in slides

• Assigned readings are background material to aid your understanding


Software Engineering

• Most large-scale software projects are challenged (over budget, behind schedule, scope reduced) or abandoned

• Most “successful” software still has issues


Five Most Common Causes of Software Project Failure

• Unrealistic Schedules

• Inappropriate Staffing

• Changing Requirements During Development

• Poor Quality Work

• Believing in Magic


No Silver Bullet

• Claim: no individual technology or practice will yield a 10-fold increase in productivity, reliability, simplicity in 10 years (from 1986)

• Further claim: substantial progress will be made over a longer period of time

• Both have proven true

• Yannis’s Law: “Programmer productivity doubles every 6 years”


Software Engineering

• Bruegge et al Definition:• Software Engineering is a collection of techniques,

methodologies and tools that help with the production of a high-quality software system developed with a given budget before given deadline while change occurs.

• IEEE Definition:1. The application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

2. The study of approaches as in (1).


Outline



• Requirements



• UML

• Design Patterns


Software Lifecycle

• Life of software from idea to deployed and maintained application


Software Development Process

• No-Method Process• Sketch, code, debug, modify, repeat

• Waterfall Model• Requirements Design Implementation

Verification Maintenance• Sequential, inflexible, lots of documentation• Can include some feedback• Assumes requirements are complete

• V-Model Model• Testing a parallel activity to development


SW Development Process (2)

• Evolutionary Model• Prototype, evaluate, then build

• Prototype Model• Prototype, evaluate, repeat until convergence

• Spiral Model• Iterate through waterfall model – 6-24 months• Generate succession of prototypes/versions• Continuous assessment of risk• Most successful approach for safety-critical

systems



• Agile• Focus on schedule• Frequent cycles of code, build, test• Every build integrated all code from the cycle

• Stable, deliverable, partially-complete system

• Features• Refactoring• Continuous integration• Pair programming• Shared code• Coding standard• Common work space• Customer as part of team• Driven by user stories



• More Agile features• Assume requirements specs will change during project

- ~50% of requirements done when project starts• But only change specs between development cycles

• Documents and code evolve together• Document with diagrams, e.g. UML

• Agile manifesto• Individuals and interactions >> processes and tools• Working SW >> comprehensive documentation• Customer collaboration >> contract negotiations• Responding to change >> following a plan


SW Process Maturity

• Capability Maturity Model (CMM)1. Initial Level

• Also called ad hoc or chaotic, may require “heros”

2. Repeatable Level• Process at least documented

3. Defined Level• Process is institutionalized (sanctioned by management)

4. Managed Level• Quantitative, agreed upon metrics, provide feedback for resource

allocation (process itself does not change)

5. Optimizing Level• Process allows feedback of information to change the process itself


Outline



• Requirements



• UML

• Design Patterns


Requirements

• Large fraction of SW system problems due to incomplete/wrong requirements

• Requirement are statements of desired behavior for a system

• Requirements process has two activities:• Requirements elicitation — definition of the system

in terms understood by the customer and/or user• Requirements analysis — definition of the system in

terms understood by the developer


Requirements Goals

• Understand the problem or problems that the eventual software system, if any, should solve

• Prompt relevant questions about the problem and system

• Provide basis for answering questions about specific properties of the problem and system

• Decide what the system should do

• Decide what the system should not do

• Ascertain that the system will satisfy needs of its stakeholders

• Provide basis for development of the system

• Provide basis for validation and verification (especially testing) of the system


Requirements Components

• Domain properties• Assumptions that are true in the domain

• Functional requirements

• Non-functional requirements• Reliability• Security• Accuracy of results• Time and space performance• Portability• …


Roles of Domain Properties vs. Requirements

• Requirement R:• “The database shall only be accessible to authorized

personnel”

• Domain Properties D:• Authorized personnel have passwords• Passwords are never shared with non-authorized personnel

• Specification S:• Access to the database shall only be granted after the user

enters an authorized password

• S, D R• But what if domain assumptions are wrong?


Quality Goals for Requirements

• Correct

• Complete

• Consistent

• Unambiguous

• Traceable

• Modifiable

• Verifiable

• Prioritized

830-1998 — IEEE Recommended Practice for Software Requirements Specifications


A Balancing Act

• One should not over-specify• == committing too early to a specific implementation

• One should not under-specify• == leaving some parts of the problem missing


Requirements Example

• Study Naur’s example

• B. Meyer definition of specification:• Precise definition of the tasks to be performed by

the system

• Requirements are a natural-language definition of the system objectives

• Favor precise, falsifiable language over pleasant generalities!


Seven Sins of Specifier

1. Noise• Irrelevant information, redundancy, remorse (restriction at use, not

definition, of an element)

2. Silence• Feature exists, but not discussed

3. Over-specification• Specification of a solution to the problem, not the problem

4. Contradiction

5. Ambiguity

6. Forward reference

7. Wishful thinking• Feature definition, for which candidate solutions cannot be

realistically validated


Complete Requirements

• Definition from IEEE standard:

An SRS (Software Requirements Specification) is complete if, and only if, it includes the following elements:

• All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated.

• Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.

• Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.


SRS Structure

1. Introduction1.1. Purpose1.2. Scope1.3. Definitions, acronyms, and abbreviations Glossary1.4. References1.5. Overview

2. Overall description2.1. Product perspective2.2. Product functions2.3. User characteristics2.4. Constraints2.5. Assumptions and dependencies

3. Specific requirements

Appendices

Index


Requirements and Agile Methods

• Under XP (Extreme Programming)• Requirements are taken into account as defined at the particular time

considered• Requirements are largely embedded in test cases

• Benefits• Test plan will be directly available• Customer involvement

• Risks• Change may be difficult (refactoring)• Structure may not be right• Tests only cover the foreseen cases

• Possibly useful advise• Retain the best agile practices, in particular frequent iterations,

customer involvement, centrality of code and testing• Disregard those that contradict proven SE principles


Techniques for Requirements Elicitation

• Questionnaires: Asking the end user a list of pre-selected questions

• Task Analysis: Observing end users in their operational environment

• Scenarios: Describe the use of the system as a series of interactions between a specific end user and the system

• Use Cases: Abstractions that describe a class of scenarios


Use Cases• The system treated as a “black box” (== the interactions

with system, including system responses, are as perceived from outside the system)

• Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals

• A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.

• Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain

• With some help from graphical notations, such as UML use case and sequence diagrams


What is UML?

• UML == Unified Modeling Language

• Nonproprietary standard for modeling software systems, OMG

• Convergence of notations used in object-oriented methods• OMT (Object Modeling Technique, James Rumbaugh and colleagues)• Booch (Grady Booch)• OOSE (Ivar Jacobson)

• Current Version: UML 2.3 (May 2010)

• Information at the OMG portal http://www.uml.org

• Commercial tools:• Rational (IBM), Together (Borland), Visual Architect (business

processes, BCD)

• Open Source tools:• ArgoUML, BOUML, Dia,…

http://www.uml.org/

http://www.uml.org/


UML Diagrams


UML Diagrams

• Use case diagrams• Describe the functional behavior of the system as seen by the

user

• Class diagrams• Describe the static structure of the system: Objects, attributes,

associations

• Sequence diagrams• Describe the dynamic behavior between objects of the system

• Statechart diagrams• Describe the dynamic behavior of an individual object

• Activity diagrams• Describe the dynamic behavior of a system, in particular the

workflow


Summary of Requirements

• Goal: SRS that describe the problem, not solution

• Variety of sources and means for eliciting requirements

• Use what makes most sense in the situation

• Variety of definition and specification techniques• Use what makes most sense in the situation

• Requirements should be validated (that they meet customer expectations)

• Specifications should be verified (that they satisfy requirements)


Outline



• Requirements



• UML

• Design Patterns


Software Configuration Management (SCM)

Software configuration management goals:• Configuration identification - identify configurations, configuration items and

baselines• Configuration control - implement controlled change process; e.g. change

control board to approve/reject change requests against a baseline• Configuration status accounting – record/report all necessary information on

status of development process• Configuration auditing – ensure configurations contain all intended parts and

are sound w.r.t. specifying documents, including requirements, architectural specs and user manuals

• Build management – manage process and tools used for system builds• Process management - ensure adherence to development process• Environment management – manage HW/SW that hosts the system• Teamwork – facilitate team interactions related to the process• Defect tracking – make sure every defect has traceability back to the sourcehttp://en.wikipedia.org/wiki/Software_configuration_management

http://en.wikipedia.org/wiki/Software_configuration_management


Why Separate Branches?

• Separation of concerns

• Less contention over the repository

• Groups commit according to common theme, allowing easier porting or roll-back


Possible Branches

• Examples• Released versions• Soon-to-be-released versions• Ongoing development

• Ideas may never show up in a release, but you never know, so don’t flush the code

• Features or topics• Hotfixes

• Branch models are generally portable among version control systems


Branch Model


Main Branches• “master”

• Each commit is tagged with a version number

• Released versions of the product are built from this branch

• “develop”• Latest set of features that will go

into the next release• Always left in a functioning state

(no work in progress)• These branches live forever• Other supporting branches have

limited lifetimes


Release Branches• “release-*”

• Whenever the “develop“ branch is feature-complete for the next release, create a release branch off of “develop“

• Only bugfixes or new metadata (like version numbers) may be committed

• This branch may periodically be merged into “develop“ to pass on the bugfixes

• When the release is complete:• Merge it into “master“ and tag• Merge it into “develop“ one last

time• Delete it


Feature Branches

• “*” (any unique name)

• Whenever a developer wants to begin work on a new feature, bugfix, refactoring,… create a feature branch off of “develop“

• Try to break commits into their smallest, independent units

• When the feature is complete and will be included in the next release:

• Merge it into “develop“• Delete it


Hotfix Branches• “hotfix-*”• Sometimes we make mistakes• Whenever we need an urgent fix

for a released version, create a hotfix branch off of “master“

• Treat it exactly like an unplanned release branch

• When a hotfix is complete:• Merge it into “master“ and tag• Merge it into “develop“• Delete it

• This model only supports hotfixes for the latest release

• If you want to support old versions after new ones have been released, then do not delete release branches


Branch Model


Configuration Management Summary

• Typical code development has graph-like dependencies

• Use version control systems to manage code

• Permits synchronization and consistency across developers

• Permits roll back to previous point in code history


Outline



• Requirements



• UML

• Design Patterns


From Requirements to Design

• S, D R• S = specification• D = domain properties• R = requirements

• Come up with a design that satisfies S


Role of Object-Oriented Analysis

• Analysis object model later refines to object model

• Analysis object and dynamic models basis of system design


Analysis

• Developers formalize requirements specification

• Examine exceptional cases, boundary conditions• Clients engaged

• OO Analysis• Developers build an object model of the application

domain• Extend model with how actors and system interact

with the application domain objects


Basic Process of Class Design

• Iterate in some order, until convergence• Identify classes• Find attributes• Find operations• Find associations between classes

• Above too vague

• Some guidance exists


Different Kinds of Objects

• Often the following categories can be identified• Suggested in: Jacobson, Booch, Rumbaugh: The Unified

Software Development Process. Addison-Wesley, 1999

• Entity objects• Represent the persistent information tracked by the system• Application domain objects, also called “Business objects”

• Boundary objects• Represent the interaction between the user and the system

• Control objects• Represent the control tasks performed by the system

• Somewhat related to a model-view-controller architecture


Outline



• Requirements



• UML

• Design Patterns


Sequence Diagrams

• Ties use cases with objects

• Shows how behavior of use case distributed among its participating objects

• More concise (and possibly more precise) than textual use case descriptions


Sequence Diagrams: Notation• Each column represents an object

• Horizontal arrows are messages or stimuli

• Vertical rectangle is an activation of an operation• Length represents time of being active• Triggered by a message• Messages can originate from operations

• Time proceeds from top to bottom

• Lifetime also depicted• Objects on top row exist from start• Other objects created with «create» messages• Vertical dashed line expresses object’s life time

• Time span an object can receive messages

• Cross depicts destruction


Sequence Diagram Conventions

• First column: initiating actor• Second column: boundary object• Third column: control object managing the rest of the

use case• Control objects created by boundary objects• Boundary objects created by control objects• Entity objects accessed by control and boundary objects• Entity objects never access control or boundary objects

• Entity objects stay reusable across use cases


Example


Example (cont.)


State Machine Diagrams

• State machines represent a system’s behavior from a single object’s perspective

• (Sequence diagrams represent a system’s behavior from a single use case’s perspective)

• Cross-checking (which actions trigger which transitions) between both views useful

• Can reveal new use cases• Can reveal missing states• Can reveal ambiguities, incoherencies


State Machine Diagrams: Notation

• Largely based on Harel’s statecharts (1987)

• Exactly like finite state machines, but features added to keep presentation manageable

• Not all states need to be shown simultaneously

• Can focus on one aspect of state independent of others

• Notation for nesting states and state machines (OR states)

• Orthogonal regions (AND states)

• Notation for triggers and actions

• Entry and exit actions

• Internal transitions


Example


Outline



• Requirements



• UML

• Design Patterns


System Design• Subsystem decomposition

• Abstraction of the machine(s)• Choosing middleware, GUI frameworks, class

libraries, database engines

• Application domain components• Possibly choosing off-the-shelf application domain

components for select domain functionality

• Object design to fill in the rest• Adapt reusable components• Identify new solution classes• Specify subsystem interfaces precisely


Object Design

• Purpose• Prepare for implementing the system model• Transform the system model for better

implementability/extensibility/performance/. . .

• Explore ways to implement the system model

• The result of object design should match the structure of the implementation


Activities• Reuse: identify and adapt existing solutions

• Off-the-shelf components• Libraries• Design patterns

• Interface specification• Specs of each class interface• APIs of subsystems

• Object model restructuring• To improve some characteristics (extensibility,

understandability, etc.)

• Object model optimization• Greater speed, lower memory use, etc.


Modularization

• Low coupling and high cohesion

• Minimize dependencies - changes localized

• Maximize unity - modules work well together

• Encapsulation – bundle data and methods, with access protection

• Enforce object invariants

• Inheritance – specification, implementation• Organization during analysis• Reuse during object design


Modularization

• Open Closed Principle – class open for extension, closed for modification

• Liskov Substitution Principle – subclass can sub for base class

• Derived methods should expect no more and provide no less (pre- and post-conditions)


Encapsulation

• BoochThe process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation

• Casual definition: bundling data and methods, with access protection

• Encapsulation enables object invariants to be enforced


Inheritance

• Where used:

1. Organization (during analysis)• Inheritance helps in expressing generalization and

specialization in taxonomies that deal with the application domain

• Primary use: discussion with domain experts and customers

2. Reuse (during object design)• Inheritance helps in reusing models and code to deal

with the solution domain• Goal is to reduce redundancy and obtain extensibility• Primary use: developers


Design Patterns Motivation

• Not every problem solved with a solution developed “from scratch”

• Desirable to reuse solutions

• Recording and cataloging experience in SW design often not done systematically, or at all

• Learning how to design starts by studying other designs


Characterizing Design Patterns

• Reusable designs

• Capturing design knowledge that• Is too “high-level” to write as an abstraction in a library

• What is too high-level depends on the language, of course

• Modifiable abstractions/designs

• Basic idea: avoid “re-inventing the wheel”

• Capture well-tested solutions to oft-occurring situations

• Modularize design!


Design PatternEach pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

Visually pleasing and practical structures for an application and/or setting could be described by a pattern language.

- Christopher Alexander• For example, desirable farmhouses in the Bernese

Oberland area of Switzerland used these patterns:North-South Axis Garden to the SouthWest-Facing Entrance Down the Slope Pitched RoofTwo Floors Half-Hipped EndHay Loft at the Back Balcony Toward the GardenBedrooms in Front Carved Ornaments


23 Patterns in GoF Book

Creational Structural Behavioral

Factory Method Adapter Command

Abstract Factory Façade Visitor

Prototype Proxy Iterator

Builder Decorator Interpreter

Singleton Composite Mediator

Flyweight Memento

Bridge Observer

Strategy

Template Method

Chain of Responsibility

State


Structure of a Design Pattern

• Four elements• A unique name• A problem description

• Situations in which the pattern applies• Problems addressed

• A solution• Stated as a set of collaborating classes and interfaces• Often uses class diagrams, sequence diagrams, state

charts, etc.

• A set of consequences that describes the trade-offs and alternatives w.r.t. the design goals the pattern addresses


GoF Book’s Pattern Structure• Pattern Name and Classification• Intent

• “Why use this pattern?”

• Also known as• Motivation (Forces)

• Often an example scenario

• Applicability• Structure

• Often class and interaction diagrams

• Participants• Classes and objects involved, and their roles

• Collaborations• How classes/objects interact

• Consequences• Implementation• Sample Code

• Concrete example of how to use the pattern (in code)

• Known Uses• Related Patterns


Composite Pattern: Motivation

There are times when a program needs to manipulate a tree data structure and it is necessary to treat both Branches as well as Leaf Nodes uniformly. Consider for example a program that manipulates a file system. A file system is a tree structure that contains Branches which are Folders as well as Leaf nodes which are Files. Note that a folder object usually contains one or more file or folder objects and thus is a complex object where a file is a simple object. Note also that since files and folders have many operations and attributes in common, such as moving and copying a file or a folder, listing file or folder attributes such as file name and size, it would be easier and more convenient to treat both file and folder objects uniformly by defining a File System Resource Interface.


Composite Pattern: Intent

• The intent of this pattern is to compose objects into tree structures to represent part-whole hierarchies

• Composite lets clients treat individual objects and compositions of objects uniformly


Composite Pattern: Implementation & Participants

Component Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.

Leaf Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.

Composite A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.

Client The client manipulates objects in the hierarchy using the component interface. A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn’t matter if the node is a composite or a leaf.


Composite Pattern: Applicability

• The composite pattern applies when there is a part-whole hierarchy of objects and a client needs to deal with objects uniformly regardless of the fact that an object might be a leaf or a branch


Example – Graphics Drawing Editor

• In graphics editors a graphic can be basic or complex. Examples of simple graphics are lines and circles, where a complex graphic is a picture containing many simple (or complex) graphics. Since simple and complex shapes have operations in common, such as rendering the graphic to a screen, and since graphics follow a part-whole hierarchy, composite pattern can be used to enable the program to deal with all graphics uniformly.


Example – Graphics Drawing Editor

In the example we can see the following actors:

Graphic (Component) Graphic is the abstraction for Line, Circle, etc. objects, (leafs) and Picture objects (composites).

Line, Circle (Leafs) Objects that have no children. They implement services described by the Graphic interface.

Picture (Composite) A Composite stores child Graphic objects in addition to implementing methods defined by the Graphic interface.

Client The Client (such as a graphical editor) manipulates Graphics in the hierarchy.


Composite Pattern: Alternative Implementation

Some methods only make sense for Composite objects, such as Add, Remove, and getChild, and in the class diagram above are thus only defined for Composite objects. Prior to calling these methods, one has to cast a Component to a Composite. Alternatively, these methods could be defined in Component, with default implementations that would do nothing.


Composite Pattern: Consequences

• The composite pattern defines class hierarchies consisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects, which in turn can be composed.

• Clients treat primitive and composite objects uniformly through a component interface which makes client code simple.

• Adding new components can be easy and client code does not need to be changed since client deals with the new components through the component interface.


Composite Pattern: Related Patterns

• Decorator Pattern• Decorator is often used with Composite. When

decorators and composites are used together, they will usually have a common parent class. So decorators will have to support the Component interface with operations like Add, Remove, and GetChild.


Composite Pattern: Known Uses

• File system implementation as discussed previously

• Graphics editors as discussed previously


Observations

• Design patterns make use of interfaces, information hiding, polymorphism, indirection

• A pattern typically consists of several classes that may have complex associations

• Design patterns can thus make a design more complex, and decrease performance

• The tradeoff between added complexity and the potential pay-offs (modularity, extensibility, portability, etc.) needs to be considered


Midterm Exam Summary

• Software Engineering – basic ideas

• Software Lifecycle – key examples, CMM

• Requirements – key issues, elicitation, good/bad practices, what you learned in HW1

• Configuration Management – why, branch diagrams

• Object Oriented Design – class design process, modularization

• UML – basic ideas for sequence, class design

• Design Patterns – what, why, know HW2 patterns

csce 431: midterm exam review. outline software engineering software lifecycle requirements...

Documents

midterm exam reviewfive

maintenance of software

development cyclesdocuments

highquality software

years csce

magic csce

feedbackassumes requirements

powerpoint presentation