Transcript Architectural Design

Architectural Design
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 11
Slide
Analysis Model -> Design Model
sc e na r i o- ba se d
e l e me nt s
Co m p o n e n t L e v e l D e sig n
f l ow- or i e nt e d
e l e me nt s
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
In t e rf a c e D e sig n
Analysis Model
c l a ss- ba se d
e l e me nt s
class diagrams
analysis packages
CRC models
collaboration diagrams
be ha v i or a l
e l e me nt s
A rc h it e c t u ra l D e sig n
state diagrams
sequence diagrams
D a t a / Cla ss D e sig n
Design Model
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 22
Slide
Analysis Model -> Design Model
What we Need:
Preliminary Design Architecture - thin client, thick
client, central, distributed
GUI Components - with layouts, navigation
Database Components – Database Tables, Segments, or Objects
Classes and Class Structure
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 33
Slide
Preliminary Design Architecture
The Preliminary Design Architecture defines the
computing environment such as:
Computers (servers, mainframes, and clients),
Operating Systems on those computers
Database Management Systems used
Communications Systems Used
Middleware used
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 44
Slide
Preliminary Design Architecture
Client
Environment
Server
Environment
TCPIP, T1
MSMQ Messages
Compaq PC
NT
Visual Basic …..
Access
Hand Readers
Cameras
VB Screens
©Ian Sommerville 2004
Compaq Server
NT
Visual Basic
MSMQ
SNA Server (COMTI)
DB Server
Environment
SNA Server(COMTI)
TCPIP
CICS Trans
T1 Line
Mainframe IBMXXX
MVS
CICS
Cobol Programs
Crystal
Reports
SQL - 7
IMS
Software Engineering, 7th edition. Chapter 4
Slide 55
Slide
Preliminary Design Architecture
If we decide to do processing on more than one computer,
we will need
A class diagram for each computer
Perhaps some communication between classes
AND PERHAPS MORE……
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 66
Slide
Design Classes



Analysis classes (domain classes) are refined
during design and more classes are added to
accommodate the design of the system.
Analysis classes generally become entity
classes (this is especially true in information
systems).
Classes are added for other items such as the
user interface, database, use cases and
communication.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 77
Slide
Interface Classes


There are two types of interface classes. The first is
the user interface display. Those are called boundary
classes.
Boundary classes are developed during design to create
the interface (e.g., interactive screen or printed reports)
that the user sees and interacts with as the software is
used.
•
Boundary classes are designed with the responsibility of
managing the way entity objects are represented to users.
Thus we need some input and output classes -- report classes
and screen classes.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 88
Slide
GUI Classes
We need :
1) the actual screens such
as HTML screens, VB
screens, Java 2 screens,
or other
2) We need the classes that
hold the code for those
screens.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 99
Slide
GUI Classes
We have a member class and
we need :
Member
name
address
phoneNumber
creditCard#
emailAddress
userName
password
©Ian Sommerville 2004
Member Screen
nameTestfield
addressTextPanel
phoneNumberTextfield
creditCard#Textfield
emailAddressTextfield
userNameTextfield
passwordTextfield
aMember
1) At least one screen for
member information.
(perhaps composed of many
panels and other components) .
2) A class for each screen
that hold the code for
THAT screen.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 10
10
Interface Classes


The second type of interface class we need is
called controller class. The boundary classes are
limited to only the display of the report or screen.
The actual control of those interface developed
during design to create
Controller classes are designed to manage
•
•
•
•
©Ian Sommerville 2004
the creation or update of entity objects;
the instantiation of boundary objects as they obtain
information from entity objects;
complex communication between sets of objects;
validation of data communicated between objects or
between the user and the application.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 11
11
Interface Classes
We have a member class and a member screen class and now we
need to control the clicks, enters, mouse navigation so we need:
Navigation Table
State
File Menu
Open
Close
New
Key FileName
Resulting State
OpenDialogue
Close Dialogue
New SpreadSheet
New SpreadSheet
……
…….
©Ian Sommerville 2004
1) A navigation diagram to
tell us how to navigate
the screen
2) A class for each
navigation that hold the
code for THAT
navigation.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 12
12
Interface Classes
Member
name
address
phoneNumber
creditCard#
emailAddress
userName
password
Member Update
Controller
aMember
aMemberScreen
©Ian Sommerville 2004
Member Screen
nameTestfield
addressTextPanel
phoneNumberTextfield
creditCard#Textfield
emailAddressTextfield
userNameTextfield
passwordTextfield
aMember
Member Create
Controller
aMember
aMemberScreen
With the screen and
navigation diagram we
create the class(es) that
hold the code for those
navigations. Multiple
navigations may be
needed for each screen
or even multiple panels
for each screen with
multiple navigations.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 13
13
Database Classes
We have a member entity on the entity relationship diagram and
a member class that has the data for the table entry and we need:
Member
MemberTable
aMember
Member
name
address
phoneNumber
creditCard#
emailAddress
userName
password
©Ian Sommerville 2004
openTable()
closeTable()
sqlMemberNameSearch()
checkMemberonFile()
A database table class
that contains the code
needed for that table.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 14
14
Use Case Classes
Register
Membership
UCRegisterMembership
aMember
aMembersScreen
aMemberScreenController
aMemberTable
©Ian Sommerville 2004
Another type of controller class
is the use case classes.
For each use case on the use case
diagram (and perhaps others you
identify as design progresses,
create a use case class.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 15
15
Use Case Classes
LogIn
Login
userID
userPassword
userPriviledges
©Ian Sommerville 2004
Another controller class is
needed for the use case
extensions and inclusions.
For each use case extension or
inclusion where the use case will
be reused, there needs to be a
controller for that use case.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 16
16
Considerations


We now have the basic additional design classes defined.
However, there are other considerations to make a
professional final cut on the classes included in this
application.
Additional classes may be needed for other items such as:
•
•
•
•
•
Additional data classes
Additional interface classes
Components
Deployment Classes
Additional architectural classes
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 17
17
Design Model Classes

Additional Data Classes
•
•

Additional Interface Classes
•
•

External interfaces to other systems, devices,
networks or other producers or consumers of
information
Internal interfaces between various design
components.
Components
•

Data model --> data structures such as lists,
collections
Data model --> database architecture such as
database management, etc
Vendor supplied or built
Deployment Classes
•
©Ian Sommerville 2004
Classes needed
to deploy
software
Software Engineering,
7th edition.
Chapter 4
Slide
Slide 18
18
Design Model Classes

Additional Architectural Classes
•
•
•
Additional Application domain classes
Relationship classes from the analysis classes
not known at analysis time
Pattern Classes
•
•
•
•
•
•
©Ian Sommerville 2004
Programming Patterns
Design Patterns
Architectural Patterns
Analysis Patterns
Framework Classes such as STRUTS type
classes
Refactored Classes
Software Engineering, 7th edition. Chapter 4
Slide
Slide 19
19
Refactoring

Fowler [FOW99] defines refactoring in the following
manner:
•

"Refactoring is the process of changing a software
system in such a way that it does not alter the
external behavior of the code [design] yet improves
its internal structure.”
When software is refactored, the existing design is
examined for
•
•
•
•
•
©Ian Sommerville 2004
redundancy
unused design elements
inefficient or unnecessary algorithms
poorly constructed or inappropriate data structures
or any other design failure that can be corrected to
yield a better design.
Software Engineering, 7th edition. Chapter 4
Slide
Slide 20
20
Use Case Packets



At this point, we have the basic classes that need to
associated with each use case.
We can put together something called a Use Case
Packet discussed later.
The Use Case Packet can be given to a
programmer for them to code the use case.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 21
21