Week6 PPT - Wikidot

fishglugΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 5 μήνες)

48 εμφανίσεις

1


SA
Capstone

Requirements
and
Design

Week 6



SYST36367
-

Winter 2013

Instructors: Jerry Kotuba & Joe Varrasso

Some slides adapted from:

Systems
Analysis and Design in a Changing World, 6th
Edition,
Satzinger
, Jackson,
Burd
,
CENGAGE Learning,
2012

2

Lesson Objectives



Analysis versus Design


Designing
the software
architecture


Design
Principles


Selecting software frameworks and components


Design
Patterns


Design
Class Diagrams


Sequence Diagrams



Systems Analysis and Design in a Changing World, 6th Edition

3

Analysis Objectives versus
Design
Objectives

Understand WHAT
is required

Design HOW to
meet requirements

Systems Analysis and Design in a Changing World, 6th Edition

4

Analysis
vs.
Design
Models

Systems Analysis and Design in a Changing World, 6th Edition

5

UML
Requirements
vs. Design
Models


Diagrams are
enhanced and
extended

Systems Analysis and Design in a Changing World, 6th Edition

6

Two Levels of Design


Architectural Design


Broad design of the overall system structure


Also called General Design and Conceptual Design


Detailed Design


Low level design that includes the design of the specific
program details


Design of each use case


Design of the database


Design of user and system interfaces


Design of controls and security

Systems Analysis and Design in a Changing World, 6th Edition

7

Design Activities:

Design the application architecture and software


Partition system into subsystems


Define software architecture


Two layer, three
layer or model
-
view
-
controller


Detailed design of each use case


Design class diagrams


Sequence diagrams


State machine diagrams

Systems Analysis and Design in a Changing World, 6th Edition

8

Design Activities
:

Design the system interfaces


Information
systems interact
with many other
systems, internal and external


Much more integration now


System interfaces connect with other systems
in many different ways


Save data another system uses


Read data another system saved


Real time request for information


Software services


Systems Analysis and Design in a Changing World, 6th Edition

9

Identifying System Interfaces

Inputs/outputs with minimal human intervention


Inputs from and outputs to other systems


These are direct interfaces with other information
systems, normally formatted as network messages.


Highly automated inputs and outputs


These are captured by devices (such as scanners) or
generated by persons who start a process that
proceeds without further human intervention.


Inputs and outputs to external databases


These can supply input to or accept output from a
system.

Systems Analysis and Design in a Changing World, 6th Edition

10

Identifying System Interfaces

Systems Analysis and Design in a Changing World, 6th Edition

11

XML for System Interfaces


Extensible Markup Language (XML)
--

extension of HTML that
embeds self
-
defining data structures within textual messages


XML tags
--

character sequences (such as <name> and </name>) that define
the beginning, end, and meaning of the text that appears between them

Systems Analysis and Design in a Changing World, 6th Edition

12


Defining System
Inputs Details


Sequence
Diagram


Details for
messages

Systems Analysis and Design in a Changing World, 6th Edition

13

Design the Environment

The design activity now in more detail


Design for Internal Deployment


Stand alone software systems


Run on one device without networking


Internal network
-
based systems


Local area network, client
-
server architecture


Desktop applications and browser
-
based
applications


Three
-
layer client server architecture


View layer, domain layer, and data layer


Desktop and browser based applications

Systems Analysis and Design in a Changing World, 6th Edition

14

Network Diagram

Internal Network System

Systems Analysis and Design in a Changing World, 6th Edition

15

Three Layer Architecture


Three Layer Client
-
Server Architecture


a client/server architecture that divides an application into view
layer, business logic layer, and data layer


View layer


the part of the three
-
layer architecture that contains the user
interface


Business logic layer or domain layer


the part of a three
-
layer architecture that contains the programs
that implement the business rules and processes


Data layer


the part of a three
-
layer architecture that interacts with the data

Systems Analysis and Design in a Changing World, 6th Edition

16

Abstract Three Layer
Architecture

Systems Analysis and Design in a Changing World, 6th Edition

17

Internal Deployment with

Three Layer Architecture

Systems Analysis and Design in a Changing World, 6th Edition

18

Design the Environment

(continued)


Design for External Deployment


Configuration for Internet deployment


Advantages and risks


Hosting Alternatives for Internet deployment


Colocation


Managed services


Virtual Servers


Cloud computing


Diversity of Client Devices with Internet
deployment


Full size, tablets and notebooks, smart phones

Systems Analysis and Design in a Changing World, 6th Edition

19

Configuration for Internet
Deployment

Systems Analysis and Design in a Changing World, 6th Edition

20

Configuration for Internet
Deployment


Advantages


Accessibility

Web
-
based applications are accessible to a
large number of potential users (including customers, suppliers,
and off
-
site employees).


Low
-
cost communication

The high
-
capacity networks that
form the Internet backbone were initially funded primarily by
governments. Traffic on the backbone networks travels free of
extra charges to the end user. Connections to the Internet can
be purchased from a variety of private Internet service providers
at relatively low costs.


Widely implemented standards

Web standards are well
known, and many computing professionals are already trained in
their use.

Systems Analysis and Design in a Changing World, 6th Edition

21

Configuration for Internet
Deployment


Potential Problems


Security

Web servers are a well
-
defined target for security
breaches because Web standards are open and widely known.
Wide
-
scale interconnection of networks and the use of Internet
and Web standards make servers accessible to a global pool of
hackers.


Throughput

When high loads occur, throughput and response
time can suffer significantly. The configuration must support not
only daily average users but also a peak
-
load number of users.


Changing standards

Web standards change rapidly. Client
software is updated every few months. Developers of widely
used applications are faced with a dilemma: Use the latest
standards to increase functionality or use older standards to
ensure greater compatibility with older user software.

Systems Analysis and Design in a Changing World, 6th Edition

22


Performance

improved by
multiple server
configurations

Systems Analysis and Design in a Changing World, 6th Edition

23

Hosting Alternatives for Internet
Deployment


Hosting
:


Running and maintaining a computer system on
someone’s behalf where the application software and
the database reside


The process of providing physical servers at a secure
location and selling those services to other
businesses that wish to deploy Web sites


Issues when considering hosting alternatives


Reliability, security, physical facilities, staff, potential
for
growth and cost


Systems Analysis and Design in a Changing World, 6th Edition

24

Hosting Alternatives for Internet
Deployment
(continued)

Systems Analysis and Design in a Changing World, 6th Edition

25

Design for Remote, Distributed
Environment


Two interfaces to same Web app for internal vs.
external access


Back end, Front end UI to same Web app


Not as secure



Virtual private network (VPN)


Closed network with security and closed access built
on top of a public network (Internet)

Systems Analysis and Design in a Changing World, 6th Edition

26

Virtual Private Network (VPN)

Systems Analysis and Design in a Changing World, 6th Edition

27

RMO’s Current Technology
Architecture

Systems Analysis and Design in a Changing World, 6th Edition

28

Object
-
Oriented Program Flow

Three Layer Architecture

Systems Analysis and Design in a Changing World, 6th Edition

29

Fundamental Design Principles


Coupling


A quantitative measure of how closely related classes
are linked (tightly or loosely coupled)


Two classes are tightly coupled of there are lots of
associations with another class


Two classes are tightly coupled if there are lots of
messages to another class


It is best to have classes that are
loosely coupled


If deciding between two alternative designs, choose
the one where overall coupling is less



Systems Analysis and Design in a Changing World, 6th Edition

30

Fundamental Design Principles


Cohesion


A quantitative measure of the focus or unity of
purpose within a single class (high or low
cohesiveness


One class has high cohesiveness if all of its
responsibilities are consistent and make sense for
purpose of the class (a customer carries out
responsibilities that naturally apply to customers)


One class has low cohesiveness if its responsibilities
are broad or makeshift


It is best to have classes that are
highly cohesive


If deciding between two alternative designs, choose
the one where overall cohesiveness is high


Systems Analysis and Design in a Changing World, 6th Edition

31

Fundamental Design Principles


Protection from Variations


A design principle that states parts of a system
unlikely to change are separated (protected) from
those that will surely change


Separate user interface forms and pages that are
likely to change from application logic


Put database connection and SQL logic that is likely
to change in a separate classes from application logic


Use adaptor classes that are likely to change when
interfacing with other systems


If deciding between two alternative designs, choose
the one where there is protection from variations


Systems Analysis and Design in a Changing World, 6th Edition

32

Fundamental Design Principles


Indirection


A design principle that states an intermediate class is
placed between two classes to decouple them but still
link them


A controller class between UI classes and problem
domain classes is an example


Supports low coupling


Indirection is used to support security by directing
messages to an intermediate class as in a firewall


If deciding between two alternative designs, choose
the one where indirection reduces coupling or
provides greater security


Systems Analysis and Design in a Changing World, 6th Edition

33

Fundamental Design Principles


Object Responsibility


A design principle that states objects are responsible for
carrying out system processing


A fundamental assumption of OO design and programming


Responsibilities include “knowing” and “doing”


Objects know about other objects (associations) and they
know about their attribute values. Objects know how to carry
out methods, do what they are asked to do.


Note that CRC cards and the design in the next chapter
involve assigning responsibilities to classes to carry out a use
case.


If deciding between two alternative designs, choose the one
where objects are assigned responsibilities to collaborate to
complete tasks (don’t think procedurally).


34

Software Components and Frameworks


Time to Market

is paramount in today’s competitive marketplace


Selecting powerful and tested frameworks and components can
save lots of development time


Systems Analysts often need to participate in “
Buy versus Build

decisions regarding components and frameworks


Capstone is designed to reflect industry best practices.
So your
team should look for components and frameworks that can speed
your development and improve your product!


Past groups have used several components and frameworks
including:


CakePHP
,
jQuery
, Kendo
UI, HTML5,
PhoneGap
, Google
Web Toolkit
(GWT),
Microsoft Entity Framework, ASP.NET MVC
, ASP.NET AJAX
Control Toolkit, Crystal
Reports, etc.



Systems Analysis and Design in a Changing World, 6th Edition

35

Design Patterns


Design Pattern

standard design techniques and
templates that are widely recognized as good practice


For common design/coding problems, the design
pattern suggests the best way to handle the problem.


They are written up in design pattern
catalogs/references. Include:


Pattern name


Problem that requires solution


The pattern that solves the problem


An example of the pattern


Benefits and consequences of the a pattern

Systems Analysis and Design in a Changing World, 6th Edition

36

Design Patterns


Design patterns became widely accepted after the
publication of
Elements of Reusable Object
-
Oriented
Software
,(1996) by Gamma et al (the “Gang of Four”)


There are architectural design patterns talked about
already


Three layer or model
-
view
-
controller architecture


The first example of a programming design pattern
shown is the Controller Pattern.


Problem is deciding how to handle all of the messages from
the view layer to classes in the problem domain layer to
reduce coupling


Solution is to assign one class between the view layer and the
problem domain layer that receives all messages and acts as
a switchboard directing messages to the problem domain


Systems Analysis and Design in a Changing World, 6th Edition

37

Controller
Pattern


First step toward
multilayer
architecture




More design
patterns are at the
end of the chapter



Systems Analysis and Design in a Changing World, 6th Edition

38

OO Detailed Design Steps

Chapters 10 and 11

Systems Analysis and Design in a Changing World, 6th Edition

39

First Cut Design Class Diagram


Proceed use case by use case, adding to the diagram


Pick the domain classes that are involved in the use
case (see preconditions and post conditions for ideas)


Add a controller class to be in charge of the use case


Determine the initial navigation visibility requirements
using the guidelines and add to diagram


Elaborate the attributes of each class with visibility and
type


Note that often the associations and multiplicity are
removed from the design class diagram as in text to
emphasize navigation, but they are often left on

Systems Analysis and Design in a Changing World, 6th Edition

40

Start with
Domain
Class

Diagram


RMO Sales
Subsystem

Systems Analysis and Design in a Changing World, 6th Edition

41

Create First
Cut Design
Class

Diagram


Use Case
Create phone
sale
with
controller
added

Systems Analysis and Design in a Changing World, 6th Edition

42

Use Case Realization with
Sequence Diagrams


Use case realization

the process of elaborating the
detailed design of a use case with interaction diagrams


Two types of interaction diagrams


UML sequence diagram (emphasized in text)


UML communication diagram (also introduced)


Sequence diagrams, aka use case realization
sequence diagrams, extend the system sequence
diagram (SSD) to show:


View layer objects


Domain layer objects (usually done first)


Data access layer objects

Systems Analysis and Design in a Changing World, 6th Edition

43

Start with
System
Sequence
Diagram
(SSD)



Use case
Create
customer
account


Systems Analysis and Design in a Changing World, 6th Edition

44

Sequence Diagram to show View Layer
and Part of Problem Domain Layer

Systems Analysis and Design in a Changing World, 6th Edition

45

Notes of Expanded Sequence Diagram


This is a two layer architecture, as the domain class
Customer knows about the database and executes SQL
statements for data access


Three layer design would add a data access class to handle
the database resulting in higher cohesiveness and loose
coupling


Note
:CustomerForm

is an object of the CustomerForm
class,
:CustomerHandler

is an object of the
CustomerHandler class playing the role of a controller
stereotype (both underlined becuase they are objects)


aC:Customer

is an object of the Customer class known by
reference variable named aC


Note: the create message to
aC:Customer

points to the
object symbol to indicate create

Systems Analysis and Design in a Changing World, 6th Edition

46

Create
Customer
Account

Use Case


Start with domain
model for
Customer
Account
Subsystem

Systems Analysis and Design in a Changing World, 6th Edition

47

Create
Customer
Account

Use Case


First cut design
class diagram for
use case


Select needed
classes,
elaborate
attributes, add
controller, and
add navigation
visibility

Systems Analysis and Design in a Changing World, 6th Edition

48

Create
Customer
Account

Use Case


First cut
sequence
diagram
expanding SSD,
adding controller,
and adding
needed classes

Systems Analysis and Design in a Changing World, 6th Edition

49

Create
Customer
Account

Use Case


Add messages
and activation to
complete
collaboration


This is just the
domain layer


These domain
classes handle
data access, so
this is a two layer
architecture

Systems Analysis and Design in a Changing World, 6th Edition

50

Assumptions


Perfect technology assumption

First encountered for use
cases. We don’t include messages such as the user
having to log on.


Perfect memory assumption

We have assumed that the
necessary objects were in memory and available for the
use case. In multilayer design to follow, we do include the
steps necessary to create objects in memory.


Perfect solution assumption

The first
-
cut sequence
diagram assumes no exception conditions.


Separation of responsibilities

Design principle that
recommends segregating classes into separate
components based on the primary focus, such as user
interface, domain, and data access


Systems Analysis and Design in a Changing World, 6th Edition

51

Implementation Issues

Three Layer Design


View Layer Class Responsibilities


Display electronic forms and reports.


Capture such input events as clicks, rollovers,
and key entries.


Display data fields.


Accept input data.


Edit and validate input data.


Forward input data to the domain layer classes.


Start and shut down the system.

Systems Analysis and Design in a Changing World, 6th Edition

52

Implementation Issues

Three Layer Design


Domain Layer Class Responsibilities


Create problem domain (persistent) classes.


Process all business rules with appropriate logic.


Prepare persistent classes for storage to the database.


Data Access Layer Class Responsibilities


Establish and maintain connections to the database.


Contain all SQL statements.


Process result sets (the results of SQL executions) into
appropriate domain objects.


Disconnect gracefully from the database.

53

Deliverable
3
(Project
Design)


Let’s review Deliverable 3 together which is due in Week 9


For detailed
instructions
and a link to the rubric please visit
:
http://
sacapstone.wikidot.com/deliverable3instructions

54

Group Meetings


Please break into your Capstone Groups to plan and
work on Deliverable 3!


We will be meeting with each group today to assess
your progress and provide some advice