UML modeling in analysis and design(week
4&5-8)
•
Modeling is a proven and well-accepted engineering
technique
•
A model is an organized
simplification of reality that provides the blueprints of a system
so that we can better understand the system we are creating and
communicate with others
•
Modeling conventions:
•
Simplify and
Organize
•
Intuitively arranged (e.g. Left
to right. Top down)
•
Clear consistent
labeling
•
Connected/related diagrams
together
•
Annotated with auxiliary
documents
•
UML is a language used to specify, visualize, and document the
artifacts of an object-oriented system under
development. It represents the
unification of the Booch, OMT, and Objectory (Jacobson ) notations,
as well as the best ideas from a number of other methodologists as
shown as next page. By unifying the
notations used by these object oriented methods, the Unified
Modeling Language provides the basis for a de facto standard in the
domain of object–oriented analysis and design founded on a wide
base of user experience
•
Unified Modeling Language:
•
A language for specifying,
constructing, visualizing and documenting the software system and
its components
•
Graphical language with sets of
rules and semantics
•
Supports the creation of models
for different purposes and different people
•
It has a tight mapping to a
family of OO languages
•
Processes:
•
Analysis:
•
Identify the
users/actors
•
Developing a simple business
process model
•
Develop the use case
•
Interaction diagrams
•
Classification: identify
classes, relationships, attributes, method; iterate and
refine.
•
Design:
•
Apply design axioms to design
classes, their attributes, methods, associations, structures, and
protocols.
•
Design the access
layer
•
Designing view layer
classes
•
Iterate and refine the design
and analysis to see if needed repeat the preceding
steps.
•
Classes and Objects
•
A class is an abstract
definition of an object. It defines the structure and behavīor of
each object in the class. It serves as a template for creating
objects
•
Objects are grouped into
classes.
•
A class has methods and
attributes while object instances have behavīors (what object can
do) and states.
•
Methods and Messages
•
Methods implement an object’s
behavīor. It analogous to a function or procedure
•
Messages are sent to trigger
methods. Procedure call from one object to the next.
•
Encapsulation & Information
Hiding
•
Principle of concealing the
internal data and procedures of an object and providing interface
to each object
•
Encapsulation: Combination of
data and process into an entity
•
Information Hiding: Only the
information required to use a software module is published to the
user
•
Reusability Key: Use an object
by calling methods
•
Polymorphism allows a message to achieve the same result even
when the mechanism for achieving it differs between different
objects
•
Inheritance
•
Superclasses or general classes
are at the top of a hierarchy of classes
•
Subclasses or specific classes
are at the bottom
•
Subclasses inherit attributes
and methods from classes higher in the hierarchy
•
Hierarchies are easy to
extend
•
Activity Diagrams
•
Activity diagrams model the
behavīor in a business process
•
An activity diagram shows the
workflow of a system. In other words, an
activity diagram shows the flow of control from activity to
activity in the system, what activities can be done in parallel,
and any alternate paths through the flow. (Quatrani,
1999)
•
Use Case Diagram
•
System boundary: Determines
what is considered external or internal system
•
Actor: Represent a role played
an outside object
•
Use Case: A set of events that
occurs when an actor uses a system to complete a
process.
•
Communicates Relationship:
Illustrates the participation of the actor in the use
case
•
Uses Relationship: It occurs
when you are describing your use cases and notice that some of them
have subflows in common.
•
Extends relationship: Create an
extending or addition use case, and within it, it extends the
behavīor of some base use case
•
Use case descrīptions
•
Captures the potential
requirements of a new system.
•
Class Diagrams
•
Associations: class can be
related to itself
•
Generalization: Generalization
shows that a subclass inherits from a superclass
•
Aggregation: Aggregation
classes comprise other classes
•
Composition
•
Sequence Diagrams
•
Illustrate the objects that
participate in a use-case
•
Show the messages that pass
between objects for a particular use-case
Innovative product and its impact in local/global analysis
and design of e-commerce systems(week 10 11 12)
Work systems
User interface
M-commerce
•
Products and services available
•
Mobile ticketing
•
Mobile vouchers, coupons and
loyalty cards
•
Content purchase and
delivery
•
Location-based
services
•
Information services
•
Mobile banking
•
Mobile StoreFront
•
Mobile brokerage
•
Auctions
•
Mobile Browsing
•
Mobile Purchase
•
Mobile marketing and
advertising
•
Main article: Mobile
marketing
Critical Success Factors
Unique characteristics
–
Timeliness (saving time,
killing time)
–
Mobility (anywhere,
everywhere)
–
Location sensitivity (exactly
where)
–
Use you own device
globally
Robust product portfolio
–
Cost-effective applications
that span a wide range of personal needs
–
Need perceived value-added over
cost
–
Try for “Snowball”
effect
Achieving critical mass
–
Valuable only if many
use
–
Threshold and gap prior to high
growth
–
Need to get beyond
innovators
–
Need to build on early
adopters
Integrated value chain
–
No disconnects
–
All parties in the chain can
benefit / share revenue (e.g., ISP / content provider /
customer)
Change in perceptions
–
Phone as a data
device
–
PDA as a wireless
communicator
Clear business case
Patience
Sufficient financing
Vendor cooperation on standards
Government encouragement
Research
RISK areas
Competing standards
Integration with legacy applications
Secure payments
High-speed wireless access
–
how fast, when and at what
price
Culture
Privacy
Device limitations
Timing of product and service offerings
WISH list
Smaller / cheaper / faster
Longer battery life
More website considerations
Easier interaction
Expanded products and services
Better integration
Robust location sensitivity
Selectable “push” applications
•
Identify and address issues in the incorporation of
selected technologies(week 1&3)
System identification, selection and planning is one of the
important steps in system development life cycle.
There are two approaches to systems
Development.
Process-Oriented Approach
–
Focus is on flow, use and
transformation of data in an information system
–
Disadvantages:
data files are tied to specific
applications
Data-Oriented Approach
–
Depicts ideal organization of
data, independent of where and how data are used
System development methodology is a formalized approach or series of
steps to support SDLC.
Structured
–
Formal
–
Step by Step
–
Emphasize on developing paper
based specifications
–
Waterfall Development Method
Project team proceed
sequentially from one phase to the next
–
Parallel Development After a general design for the whole system, the
project is divided into subprojects that can be designed and
implemented in parallel
Rapid
Application Development (RAD)
–
Emphasize quick creation of a
limited-capability version of the system
–
Focus on refining the
preliminary system
–
Phased Development Break overall system into versions that are
developed sequentially
–
Prototyping A “quick-and-dirty” program that provides a
minimal amount of features; Not for the development of complex
systems
–
Throwaway Prototyping Usually used when there are challenging
technical issues
Object-Oriented Analysis & Design
(OOAD)
Attempt to balance emphasis on data and
process
Uses Unified Modeling Language (UML)
Characteristics of OOAD:
–
Use-case Driven
–
Architecture Centric
–
Iterative and
Incremental
Custom develop (Build)?
Build a system in-house with the company’s own
developers
Advantages:
–
Have complete control over
system functionality
–
Allows for meeting highly
specialized requirements
–
Allows flexibility and
creativity in solving problems
–
Easier to change components in
the future
Disadvantages:
–
Customers may not know what
they need
–
Customers may change their
mind
–
Easy to say “yes” to changes
and get behind schedule
–
Keeping developers can be
costly
–
Can be difficult to stabilize
new systems
–
Developers may be pulled away
to work on other projects
–
May be difficult to get
extended funding
–
Developers may not have
sufficient technical expertise
Buy (or lease)?
Advantages:
–
Increasing amounts of
commercial off-the-shelf software (COTS)
–
Creative financing
arrangements
–
Saves time
–
Often cheaper
–
Requires less dedicated
personnel
–
You know what you are getting
before you invest
–
You’re not the first and only
user
(thoroughly tested)
Disadvantages:
–
Software may not meet your
needs
–
Software may be difficult or
impossible to modify or require huge process changes
–
Loss of control over
improvements and new versions
–
Can be difficult to integrate
with existing systems
–
Vendor may drop product or go
out of business
Remodel?
Advantages:
–
Most likely have some systems
that work reliably that you want to keep
–
Often cheaper than building or
buying
–
Often faster than building or
buying
–
Fewer conversion
problems
–
Lower probability of
organizational disruption
–
Typically easier to
implement
Disadvantages:
–
Old systems may require so much
change that it’s easier to start over
–
Old software may be
un-salvageable (e.g., spaghetti code and/or poor
documentation)
–
Old software may require
outdated, expensive hardware
–
Can occasionally lead to
“creeping” continual change that is never finished
Some combination?
Try to achieve benefit from build, buy and remodeling
advantages without suffering the disadvantages
Hybrid
Process Models
–
Large systems
are usually made up of several sub-systems
–
The same process model need not
be used for all subsystems
–
Prototyping for high-risk
specifications
–
Waterfall model for
well-understood developments
Gap Analysis
–
Assesses the difference between stated requirements and
existing systems to create a provisioning strategy
–
Involves making tradeoffs between what the business would
ideally like and what it is realistic to expect
Component-based Development
–
A component must be capable of being connected to other
components to form a larger group or system
–
Component-based development is accomplished by integrating
previously developed components
–
Advantages:
–
Can develop quasi-customized systems
–
Can be quick and reliable
–
Can be more easily maintained
–
Doesn’t require as much programming special
expertise
–
Enables more schedule and resource flexibility
–
More easily linked to systems in other
organizations
–
Disadvantages:
–
May not be able to find the components with the right
functions and features
–
Components may be of dubious quality and not perform as
advertised
–
Component suppliers may not be cooperative or may go out of
business
–
May have difficulty interfacing components to existing
systems
–
May have difficult integrating components from different
vendors
Describe process and approach to establish ecommerce
application portfolio for a case(week 2)
Sources of projects
–
Management and business units
–
Managers who want to make a system more
efficient
–
Formal planning groups
–
Board of directors
–
Customers
–
Vendors and business partners
–
Government
–
Competitive pressure
Projects are identified by
–
Top management
–
Steering committee
–
User departments
–
Development group or senior IS staff
–
Top Down
Identification
–
Senior management or steering committee
–
Focus is on global needs of organization
–
Bottom up
Identification
–
Business unit or IS group
–
Don’t reflect overall goals of the organization
Project
Development Factors:
–
Perceived needs of the organization
–
Existing systems and ongoing
projects
–
Resources available
–
Evaluation criteria
评价标准
–
Current business conditions
–
Perspectives of the decision makers
决策者观点
–
Competitive advantage
利益竞争
–
Shareholder pressure
股东压力
–
Customer expectations
顾客期望
Steps in the system development process:
System identification, selection and planning
System analysis
System design
System implementation
–
Requirements determination is the single most critical step of the
entire SDLC.
–
Creating the requirement
definition is an iterative and ongoing process through out the
analysis phase.
–
New requirements evolved during
later phases need to be carefully managed.
–
Need to design e-commerce
systems with change and evolution in mind
–
Need to start building with
specification uncertainty
–
Gather information many sources (internal and
external):
–
Participation in strategy
sessions
–
Business plan
–
Users/customers
–
Processes/Procedures
–
Forms/Reports
–
Consultants and industry
surveys
–
Business partners
–
Competitors
Functional requirements flow directly into the next steps of the analysis
process (use cases, process models, data model) because they define
the functions that the system needs to have
Nonfunctional requirements influence the rest of the analysis process, but
often do so indirectly.
4 types:
–
Operational: The physical and
technical environments in which the system will operate
–
Performance: The speed,
capacity and reliability of the system
–
Security: Who has authorized
access to the system under what circumstances
–
Cultural and Political:
Cultural, political factors and legal requirements that affect the
system
Requirements Definition Report: correct? Completed? Verifiable?
Determining Requirements:
Traditional:
–
Interviewing and
Listening
–
Administering
Questionnaires
–
Questionnaires
–
Focus Groups
–
Directly Observing
Users
–
Indirectly Observing Users
(system logs)
Advanced:
–
Traditional methods are still
applicable to e-commerce analysis and design but newer approaches
exist that are especially useful
–
Dynamic Models, data
–
Technology support,
groupware
–
Electronic Joint Application Development
(eJAD):
–
Purpose: collect system
requirements simultaneously from key people
–
Prototyping using components
–
Quickly converts requirements
to working version of system
–
Goal: to develop concrete
specifications for ultimate system and sometimes something usable
in interim
Analyzing Procedures and Other Documents
Types of information to be discovered:
–
History of problems with
existing systems
–
Opportunity to meet new
need
–
Organizational
direction
–
Names of key
individuals
–
Values of
organization
–
Special information processing
circumstances
–
Rules for processing
data
–
Organization power and
politics
Potential sources of resistance
Potential collaborators and
partners
Use some requirement development strategies: Business
Process Management (BPM)
The basic process of analysis is divided
into:
–
Understanding the as-is
system
–
Identifying
improvements
–
Developing requirements for the
to-be system
There are 3 requirements analysis
strategies
–
Business process
automation
–
Business process
improvement
–
Business process
reengineering
Search for and implementation of radical change in
business processes to achieve breakthrough improvements in products
and services
Duration Analysis
–
Calculate time needed for each
process step
–
Calculate time needed for
overall process
–
Compare the two – a large
difference indicates a badly fragmented process
写九宫格日记
