Introduction to Computer Science

1
Week 1
2
The Analyst as a Business Problem Solver

• Analyst background computer technology,
  object-oriented analysis and design, curiosity  
• Chief task define problem and outline solution
• Challenge develop alternatives consistent with
  corporate strategic
• Develop system requirements and design models
• Systems design models databases, user
  interfaces, networks, operating procedures,
  conversion plans, and, software classes

3
Figure 1-1 The Analysts Approach to Problem
Solving
Fig 1-1A
Fig 1-1B
4
Information Systems

• Information system collects, processes, stores,
  and outputs information
• Subsystem components of another system
• Components hardware, software, inputs, outputs,
  data, people, and procedures
• Supersystem collection of systems
• Automation boundary separates automated part of
  system from manual (human)

5
Figure 1-3 Information Systems and Component
Parts
6
Types of Information Systems

• There are many types of information systems
• Six common systems are found in most businesses
• Business systems center around transactions
• Systems must adapt to changing technology

7
Figure 1-5 Types of Information Systems
8
Required Skills of the Systems Analyst

• Analysts manage issues ranging from technical to
  interpersonal
• Analyst must commit to lifelong learning

9

Figure 1-6 Required Skills of the Systems Analyst
10
Technical Knowledge and Skills

• Analysts should grasp many types of technology
• Analysts should be informed of tools and
  techniques
• Common software tools IDEs and CASE
• Common techniques
• Project planning
• Cost-benefit analysis
• Architectural Analysis

11
Business Knowledge and Skills

• Analysts should understand organizational
  structure
• Analysts should understand business concern
• Many analysts formally study business
  administration
• CIS and MIS majors often included in business
  colleges

12
People Knowledge and Skills

• Knowledge of people centers around thinking and
  feeling
• People knowledge used to adapt systems to users
• Most critical skill ability to listen
  empathetically

13
The Environment Surrounding the Analyst

• Occupational environment is not fixed
• Analysts will encounter many types of technology
• Analysts will work in many locations
• Analysts are assigned a variety of job titles

14
Types of Technology

• Wide range from desktops to large scale
  information systems
• Variety of computers connected by complex
  networks
• Technology change is continuous
• Innovation often drives information system change
• Regular upgrades of knowledge and skills essential

15
A Few Words about Integrity and Ethics

• Sense of personal integrity and ethics essential
• Analysts often encounter personal information
• Analysts encounter confidential proprietary
  information
• Keep confidential and sensitive information
  private
• Improprieties can ruin an analysts career

16
 The Traditional Predictive SDLC Approaches

• Five activities or phases in a project
• Planning, analysis, design, implementation,
  support
• Pure waterfall approach (predictive SDLC)
• Assumes project phases can be sequentially
  executed
• Project drops over the waterfall into the next
  phase
• Modified waterfall approach
• Tempers pure waterfall by recognizing phase
  overlap
• Informs many current projects and company systems

17
Figure 2-3 SDLC Phases and Objectives
18
Figure 2-4 The Waterfall Approach to the SDLC
19
The Newer Adaptive Approaches to the SDLC

• The spiral model early form of adaptive SDLC
• Activities radiate from center starting point
• Prototypes are artifacts of each phase
• Iterative problem solving repeats activities
• Several approaches to structuring iterations
• Define and implement the key system functions
• Focus on one subsystem at a time
• Define by complexity or risk of certain
  components
• Complete parts incrementally

20
Figure 2-6 The Spiral Life Cycle Model
21
The Unified Process Life Cycle

• UP life cycle
• Includes (4) phases which consist of iterations
• Iterations are mini-projects
• Inception develop and refine system vision
• Elaboration define requirements and core
  architecture
• Construction continue design and implementation
• Transition move the system into operational mode

22
Unified Process
23
Figure 2-8 The Unified Process System Development
Life Cycle
24
Figure 2-9 UP Phases and Objectives
25
Methodologies and System Development Processes

• System development methodology
• Provides guidelines every activity in system
  development
• Includes specific models, tools, and techniques
• UP is a system development methodology
• Process is a synonym for methodology
• Methodologies supported with documentation

26
Models

• Model abstract (separate) aspects of the real
  world
• Models come in many forms
• Physical analogs, mathematical, graphical
• System development models are highly abstract
• Depict inputs, outputs, processes, data, objects,
  interactions, locations, networks, and devices
• Unified Modeling Language (UML) standard
  notation
• PERT or Gantt charts model project itself

27
Figure 2-10 Some Models used in System
Development
28
Tools

• Tool software used to create models or
  components
• Example tools
• Project management software tools (Microsoft
  Project)
• Integrated development environments (IDEs)
• Code generators
• Computer-aided system engineering (CASE)

29
Techniques

• Technique
• Collection of guidelines
• Enables an analyst to complete an activity or
  task
• Example techniques
• Domain-modeling , use case modeling,
  software-testing, user-interviewing techniques,
  relational database design techniques
• Proven techniques are embraced as Best Practices

30
Figure 2-13 Relationships of Models, Tools, and
Techniques in a System Development Methodology
31
The Unified Process as a System Development
Methodology

• UP object-oriented system development
  methodology
• UP should be tailored to organizational and
  project needs
• Project will be use case driven

32
The Unified Process as a System Development
Methodology (continued)

• Use case
• Activity that the system carries out
• Basis for defining requirements and designs
• UP defines disciplines within each phase
• Discipline set of functionally related
  activities
• Iterations concatenate activities from all
  disciplines
• Activities in each discipline produce artifacts
  models, documents, source code, and executables

33
Figure 2-15 UP Life Cycle with Phases,
Iterations, and Disciplines
34
The UP Disciplines

• Six main UP development disciplines
• Business modeling, requirements, design,
  implementation, testing, and deployment
• Each iteration
• Similar to a mini-project
• Results in a completed portion of the system
• Three additional support disciplines
• Project management, configuration and change
  management, and environment

35
Business Modeling

• Purpose understand business environment
• Three major activities part of business modeling
• Understand surroundings
• Create the system vision
• Create business models

36
Requirements

• Objective document business requirements
• Key drivers of activities discovery and
  understanding
• Requirements discipline and business modeling map
  to traditional systems analysis
• Activities list
• Gather detailed information
• Define functional and nonfunctional requirements
• Develop user interface dialogs
• Evaluate requirements with users

37
Design

• Objective design system based on requirements
• Six major activities in the design discipline
• Design support services architecture and
  deployment environment
• Design the software architecture
• Design use case realizations
• Design the database
• Design the system and user interfaces
• Design the system security and controls

38
Implementation

• Objective build or acquire needed system
  components
• Implementation activities
• Build software components
• Acquire software components
• Integrate software components

39
Testing

• Testing is critical discipline
• Testing activities
• Define and conduct unit testing
• Define and conduct integration testing
• Define and conduct usability testing
• Define and conduct user acceptance testing
• In UP, acceptance testing occurs throughout the
  building phase

40
Deployment

• Goal conduct activities to make system
  operational
• Deployment activities
• Acquire hardware and system software
• Package and install components
• Train users
• Convert and initialize data
• Deployment activities prominent in transition
  phase

41
Project Management

• Most important support discipline
• Project management activities
• Finalize the system and project scope
• Develop the project and iteration schedule
• Identify project risks and confirm feasibility
• Monitor and control the projects plan
• Monitor and control communications
• Monitor and control risks and outstanding issues

42
Configuration and Change Management

• Configuration and change discipline pertains to
• Requirements
• Design
• Source code
• Executables
• The two activities in this discipline
• Develop change control procedures
• Manage models and software components

43
Environment

• Development environment includes
• Available facilities
• Design of the workspace
• Forums for team communication and interaction
• Environment discipline activities
• Select and configure the development tools
• Tailor the UP development process
• Provide technical support services

44
Overview of Object-Oriented Concepts

• OOA views system as a collection of objects
• Object entity capable of responding to messages
• Languages Simula, C, Java, C, Visual Basic
  .NET
• Object-oriented design (OOD)
• Defines additional types of communication objects
  
• Shows how the objects interact to complete tasks
• Refines definition of objects for implementation
• Object-oriented programming (OOP) object coding

45
Characteristics of Object-Oriented Systems

• Classes and Objects A class is a template used
  to define and create objects. Every object is
  associated with a class. An object has
  attributes that describe the information about
  the object. Each object has behaviors that
  specify what the object can do.
• Methods and Messages Methods implement an
  objects behavior. A method is nothing more than
  an action that an object can perform. Messages
  are information sent to objects to trigger
  methods. Basically, a message is a function or
  procedure call from one object to another object.

46

• Encapsulation and Information Hiding The ideas
  of encapsulation and information hiding are
  interrelated in OO systems. Encapsulation is the
  combination of process and data into a single
  entity. Information hiding suggests that only the
  information required to use a software module be
  published to the user of the module. Exactly how
  the module implements the required functionality
  is not relevant.
• Inheritance This is used to identify
  higher-level or more general classes of objects.
  Common sets of attributes and methods can be
  organized into superclasses or parent classes.
  The relationship between the class and its
  superclass is known as a Is A relationship.
  For example, a heart surgeon Is A doctor.
  Subclasses or child classes inherit appropriate
  attributes and methods from the superclass above
  them in the class hierarchy.

47

• Polymorphism and Dynamic Binding Polymorphism
  means that the same message can be interpreted
  differently by different classes of objects.
  Because we are not concerned with how something
  is done, we can simply send a message to an
  object and that object will be responsible for
  interpreting the message appropriately.
  Polymorphism is made possible through dynamic
  binding. Dynamic, or late binding, is a technique
  that delays typing the object until run-time. As
  such, the specific method that is actually being
  called is not chosen by the OO system until the
  system is running. This is in contrast to static
  binding where the object type is determined at
  compile time.

48
 Recognizing the Benefits of OO Development

• Original application of object-oriented
  technology
• Computer simulations
• Graphical user interfaces
• Rationale for use in information systems
• Benefits of naturalness
• Reusability
•  

49
Objects Are More Natural

• OO approach mirrors human perception objects
  moving through space
• OOA, OOD, and OOP imitate perceptual processes
  by modeling classes of objects
• Some system developers resist OO development
• New programmers are more receptive to OO approach
• System users appreciate object-orientation
• They discuss the objects involved in their work
• Hierarchies are common tools for organizing
  knowledge

50
Classes of Objects Can Be Reused

• Classes of objects have a long shelf life
• Example Customer class adaptability
• Reused in systems where customer objects needed
• Extended through inheritance to a new subclass
• Reused during analysis, design, or programming
• Classes may be stored, with implementation
  hidden, in class libraries

51
Understanding Object-Oriented Concepts

• Object thing with attributes and behaviors
• Types of objects
• User interface
• Problem domain objects
• Attributes are associated with data
• Behaviors are associated with methods, functions,
  and procedures

52
Figure 2-18 Attributes and Methods in Problem
Domain Objects
53
Understanding Object-Oriented Concepts (continued)

• Class defines what all objects of class
  represent
• Objects are instances of a class
• Customer object is an instance of a customer
  class
• Objects interact through messages
• Objects retain memory of transactions

54
Figure 2-20 Order-processing system where objects
interact by sending messages
55
Understanding Object-Oriented Concepts (continued)

• Objects maintain association relationships
• Encapsulation combining attributes and methods
  into one unit
• Information hiding separating specification from
  implementation
• Inheritance extending the characteristics of a
  class
• Polymorphism ability for dissimilar objects to
  respond to the same message

56
Figure 2-22 Superclasses and Subclasses
57
Tools to Support System Development

• CASE (Computer Aided System Engineering)
• Database repository for information system
• Set of tools that help analysts complete
  activities
• Sample artifacts models, automatically generated
  code
• Variations on CASE
• Visual modeling tools
• Integrated application development tools
• Round-trip engineering tools

58
Figure 2-24 A Case Tool Repository Contains All
Information About the System
59
Tools to Support System Development (continued)

• Microsoft Visio emphasizes technical drawing
• Rational Rose
• CASE tool supporting object-oriented approach
• Strongly identified with  UP methodology
• Together
• Pioneers round-trip engineering
• synchronizes graphical models with generated
  program code
• Leverages UML diagrams

60
(No Transcript)
61
(No Transcript)
62
(No Transcript)
63
(No Transcript)
64
Actor Generalization

• Actor generalization factors out behavior common
  to two or more actors into a parent actor.
• In order to determine if you have a situation
  that can use actor generalization, look for a
  high degree of commonality between actors.
• Do two actors communicate with the same set of
  use cases in the same way?
• If there is, you can factor out common actor
  behavior into a more generalized actor.
• You will have a parent actor and one or more
  descendent actors.
• The descendant actors inherit the roles and
  relationships to use cases held by the parent
  actor. You can substitute a descendent actor
  anywhere the parent actor is expected.

65
Actor Generalization
66
Use-Case Generalization

• Use-case generalization factors out behavior
  common to one or more use cases into a parent use
  case.
• It is used when you have one or more use cases
  that are really specializations of a more general
  use case.
• The child use cases represent more specific forms
  of the parent. The children may
• inherit features from their parent use case
• add new features
• override (change) inherited features.

67
Use-Case Generalization