Transcript System models

Software Engineering
Software Design Models
UML
Where
Phaseare we?
Actions
Outcome
Initiation
Raising a business need
Business
documents
Requirements
Interviewing stakeholders, exploring
the system environment
Organized
documentation
Specification
Analyze the engineering aspect of the
system, building system concepts
Formal
specification
Design
Define architecture, components, data
types, algorithms
Formal
Specification
Program, build, unit-testing, integrate,
Implementation documentation
Testable system
Testing &
Integration
Integrate all components, verification,
validation, installation, guidance
Testing results,
Working sys
Maintenance
Bug fixes, modifications, adaptation
System
versions
Requirements vs. Design

Requirements:
•
•

What the system
should do
More abstract
Design:
•
•
How the system
should do it
More detailed
Object models


Object models describe the system in
terms of object classes
An object class is an abstraction over a
set of objects with common attributes and
the services (operations) provided by
each object
The Unified Modelling Language

The Unified Modelling Language is a standard
graphical language for modelling object oriented
software
• At the end of the 1980s and the beginning of 1990s,
the first object-oriented development processes
appeared
• In 1995, another methodologist, Jacobson, joined
the team
» His work focused on use cases
• In 1997 the Object Management Group (OMG)
started the process of UML standardization
5
History of UML
Overview of UML Diagrams
Structural
Behavioral
: behavioral features of a system / business
process
: element of spec. irrespective of time

Activity
State machine
Use case

Interaction







Class
Component
Deployment
Object
Composite structure
Package

Interaction
: emphasize object interaction
• Communication(collaberati
on)
• Sequence
• Interaction overview
• Timing
Diagrams in UML
A diagram is the graphical representation of a set of
elements, usually rendered as a connected graph of vertices
(things) and arcs (relationships).
• Class diagram shows a set of classes, interfaces, and
collaborations with their relationships.
• Object diagram shows a set of objects and their
relationships.
• Use case diagram shows a set of use cases and actors (a
special kind of class) and their relationships.
Diagrams in UML (continued)
• Interaction diagram shows an interaction,
consisting of a set of objects and the relationships,
including the messages that may be dispatched
among them.
=> A sequence diagram emphasizes the time
ordering.
=> A collaboration diagram emphasizes the
structural organization of the objects that send and
receive messages.
Diagrams in UML (continued)
• Statechart diagram shows a state machine
consisting of states, transitions, events, and activities.
• Activity diagram is a statechart diagram that shows
the flow from activity to activity within a system.
• Component diagram shows the organization and
dependencies among a set of components.
• Deployment diagram shows the configuration of
processing nodes and the components that live on them.
UML Class Diagrams

The main symbols shown on class diagrams are:
•
•
•
•
•
Classes
 represent the types of data themselves
Associations
 represent linkages between instances of classes
Attributes
 are simple data found in classes and their instances
Operations
 represent the functions performed by the classes and
their instances
Generalizations
 group classes into inheritance hierarchies
11
Notation: Classes
Window
name
origin
size
attributes
open()
close()
move()
display()
operations
A class is a description of a set of objects that share the same
attributes, operations, relationships and semantics.
Classes

A class is simply represented as a box with the
name of the class inside
•
•
The diagram may also show the attributes and operations
The complete signature of an operation is:
operationName(parameterName: parameterType …):
returnType
Rectangle
Rectangle
Rectangle
Rectangle
Rectangle
ge tArea
he igh t
he igh t
he igh t: int
resize
width
width
width: int
ge tArea
ge tArea(): in t
resize
resize (in t,in t)
13
Employee object class (UML)
E m p loy e e
n a m e : st rin g
a d d re s s: s trin g
d a t e O fB irt h : Da t e
e m p lo ye e N o : in te g e r
s o cia lS e c u rity No : s trin g
d e p a rt me n t : De p t
ma n a g e r: E mp lo y e e
s a la ry : in te g e r
s ta t u s: {cu rre n t , le ft , re tire d }
t a xC o d e : in te g e r
. ..
jo in ()
le a v e ()
re t ire ()
c h a n g e De t a ils ()
Object diagram
Notation: Interface
ISpelling
An interface is a collection of operations that specify a
service of a class or component, i.e., the externally
visible behavior of that element.
UML associations



Objects and object classes participate in
relationships with other objects and object
classes
In the UML, a generalised relationship is
indicated by an association
Associations may be annotated with
information that describes the association
An association model
Em p lo yee
i s-m em ber-of
Dep artm en t
i s-m anag ed-b y
m anag es
M anag er
Labelling associations
•
Each association can be labelled, to make explicit the nature of the
association
Employee
*
Secretary
*
w or ksFor
Company
1..* *
Manager
super visor
Company
Office
Person
BoardOfDirectors
0..1
0,3 ..8
boar dMember
allocatedTo
*
*
Employee
BoardOfDirectors
Analyzing and validating associations
• One-to-one
» For each company, there is exactly one board of
directors
» A board is the board of only one company
» A company must always have a board
» A board must always be of some company
Company
BoardOfDirectors
Analyzing and validating associations
• Many-to-many
» A secretary can work for many managers
» A manager can have many secretaries
» Secretaries can work in pools
» Managers can have a group of secretaries
» Some managers might have zero secretaries.
» Is it possible for a secretary to have, perhaps
temporarily, zero managers?
Secretary
*
1..* *
supervisor
Manager
Analyzing and validating associations


Avoid unnecessary one-to-one associations
Avoid this
Person
na me
do this
PersonInfo
Person
ad dres s
na me
ema il
ad dres s
birthd ate
ema il
birthd ate
A more complex example
• A booking is always for exactly one passenger
» no booking with zero passengers
» a booking could never involve more than one
passenger.
• A Passenger can have any number of Bookings
» a passenger could have no bookings at all
» a passenger could have more than one booking
Passenger
*
Booking
*
SpecificFlight
Association classes
• Sometimes, an attribute that concerns two
associated classes cannot be placed in either of the
classes
• The following are equivalent
*
Student
*
CourseSection
Registration
grade
Student
*
Registration *
CourseSection
grade
2
Reflexive associations
• It is possible for an association to connect a class
to itself
successor
* Course
*
*
isMutuallyExclusiveWith
*
prerequisite
2
Directionality in associations
•
•
Associations are by default bi-directional
It is possible to limit the direction of an association by adding an
arrow at one end
Day
*
Note
Generalization

Specializing a superclass into two or more subclasses
•
The discriminator is a label that describes the criteria used in the
specialization
Animal
Animal
typeOf Food
habitat
AquaticAnimal
LandAnimal
Carnivore
Herbivore
2
Avoiding unnecessary generalizations
Inappropriate hierarchy of
classes, which should be
instances
Recording
VideoRecod ing
MusicVideo
Recording *
hasCategory
title
artist
JazzRecording
RecordingCategory
*
subcategory
description
:RecordingCategory
:RecordingCategory
video
audio
subcategory
subcategory
subcategory
AudioRecording
subcategory
ClassicalRecording
RockRecording
Improved class diagram,
with its corresponding
instance diagram
subcategory
:RecordingCategory
:RecordingCategory :RecordingCategory
:RecordingCategory :RecordingCategory
music video
jazz
blues
classical
BluesRecording
rock
:Recording
:Recording
9th Symphony
Beethoven
Let it be
The Beatles
Instance Diagrams
• A link is an instance of an association
» In the same way that we say an object is an instance of
a class
Pat:Employee
Wayne:Employee
OOCorp:Company
OOCorp's Board:
UML inc:Company
UML inc's Board
Ali:Employee
Carla:Employee
Terry:Employee
Associations versus generalizations in
instance diagrams
• Associations describe the relationships that will
exist between instances at run time.
» When you show an instance diagram generated from a
class diagram, there will be an instance of both classes
joined by an association
• Generalizations describe relationships between
classes in class diagrams.
» They do not appear in instance diagrams at all.
» An instance of any class should also be considered to
be an instance of each of that class’s superclasses
Composition
• A composition is a strong kind of
aggregation
» if the aggregate is destroyed, then the parts are
destroyed as well
Building
*
Room
• Two alternatives for addresses
Employee
ad dres s: Ad dress
Employee
Address
stree t
mun icip ality
regio n
cou ntry
po sta lCo de
Object aggregation
Detailed Example: A Class Diagram for
Genealogy
Person
na m e
se x
pla ce OfB irth
da teOfBirth
pla ce OfDe ath
{ husband.sex
= #male}
da teOfDe ath
pla ce OfMa rria ge
husband
0..1
0..1
child
da teOfMa rraig e
*
da teOfDivo rce
w ife
{ w if e.sex
= #f emale}
parent
2
{ par ent- >f orAll(p1,p2:
p1 <> p2
implies p1.sex <> p2.sex)}
• Problems
» A person must have two parents
» Marriages not properly accounted for
Genealogy
solutions
example:
Possible
Person
Person
name
sex
placeOfBirth
dateOfBirth
placeOfDeath child
dateOfDeath *
partner
* 0..2
{partner->forAll(p1,p2 |
p1 <> p2
implies p1.sex <> p2.sex)}
*
name
placeOfBirth
dateOfBirth
placeOfDeath child
dateOfDeath *
Woman
Union
0..1
placeOfMarriage parents
dateOfMarriage
dateOfDivorce
Man
femalePartner
0..1 * 0..1
child
childmalePartner
*
*
Union
0..1
placeOfMarriage
parents
dateOfMarriage
dateOfDivorce
3
An example
associations)
(attributes
and
Employee
Passenger
name
employeeNumber
jobFunction
name
number
RegularFlight
*
supervisor
*
*
Booking
seatNumber
*
*
*
SpecificFlight
date
time
flightNumber
An example (generalization)
PersonRole 0..2
Person
name
idNumber
EmployeeRole
PassengerRole
jobFunction
RegularFlight
*
supervisor
time
flightNumber
*
*
Booking
seatNumber
*
*
*
SpecificFlight
date
3
Generalisation and inheritance




Objects are members of classes which define
attribute types and operations
Classes may be arranged in a class hierarchy
where one class (a super-class) is a generalisation of
one or more other classes (sub-classes)
A sub-class inherits the attributes and
operations from its super class and may add
new methods or attributes of its own
Generalisation in the UML is implemented as
inheritance in OO programming languages
A generalisation hierarchy
E m p loy e e
Ma nager
P ro g ra m me r
b u d g e t sC o n tro lle d
d a t e A p p o in te d
P ro je c t
M a n ag e r
p ro je c ts
De p t.
Ma nager
dept
p ro je c t
p ro g L a n g u a g e
S t ra te g ic
Ma n ag e r
re s p o n sib ilit ie s
Multiple inheritance



Rather than inheriting the attributes and services
from a single parent class, a system which supports
multiple inheritance allows object classes to inherit
from several super-classes
Can lead to semantic conflicts where
attributes/services with the same name in different
super-classes have different semantics
Makes class hierarchy reorganisation more complex
Multiple inheritance
B o ok
Vo ice record in g
Au th or
Ed it io n
P u bl icat io n d at e
IS B N
S p eaker
Du rat io n
Record in g d at e
Talk in g bo ok
# Tapes
Noun Identification: A Library
Example
The library contains books and journals. It may have several
copies of a given book. Some of the books are reserved for
short-term loans only. All others may be borrowed by any
library member for three weeks. Members of the library can
normally borrow up to six items at a time, but members of
staff may borrow up to 12 items at one time. Only members
of staff may borrow journals.
The system must keep track of when books and journals are
borrowed and returned and enforce the rules.
Noun Identification: A Library
Example
The library contains books and journals. It may have several
copies of a given book. Some of the books are reserved for
short-term loans only. All others may be borrowed by any
library member for three weeks. Members of the library can
normally borrow up to six items at a time, but members of
staff may borrow up to 12 items at one time. Only members
of staff may borrow journals.
The system must keep track of when books and journals are
borrowed and returned and enforce the rules.
Candidate Classes
Library
Book
Journal
Copy
ShortTermLoan
LibraryMember
Week
MemberOfLibrary
Item
Time
MemberOfStaff
System
Rule
the name of the system
event
measure
repeat
book or journal
abstract term
general term
general term
Relations between Classes
Book
Journal
Copy
LibraryMember
Item
MemberOfStaff
Is Item needed?
is an
is an
is a copy of a
Item
Item
Book
is a
LibraryMember
Operations
LibraryMember
borrows
Copy
LibraryMember
returns
Copy
MemberOfStaff
borrows
Journal
MemberOfStaff
returns
Journal
Item not needed yet.
Class Diagram
MemberOfStaff
LibraryMember
1
1
on loan
on loan
0..12
Journal
0..*
Copy
is a copy of Book
1..*
1
Representing Architecture: The
4+1 View Model
Logical
View
Analysts/
Designers
Structure
End-user
Functionality
Process
View
System Integrators
Performance
Scalability
Throughput
Implementation
View
Use-Case
View
Programmers
Software management
Deployment
View
System Engineering
System topology
Delivery, installation
communication
Major Workflows Produce Models
Business
Modeling
supported by
Business Model
Requirements
realized by
Use-Case
Model
Analysis &
Design
implemented by
Design
Model
verified by
Implementation
Implementation
Model
Test
48
Test
Model
Use case modeling




Use cases were developed originally to support
requirements elicitation and now incorporated into
the UML.
Each use case represents a discrete task that involves
external interaction with a system.
Actors in a use case may be people or other systems.
Represented diagramatically to provide an overview
of the use case and in a more detailed textual form.
Use cases diagram
UML 2 Use cases diagrams describes the behavior of the
target system from an external point of view. Use cases
describe "the meat" of the actual requirements.

Use cases. A use case describes a sequence of actions
that provide something of measurable value to an actor
and is drawn as a horizontal ellipse.

Actors. An actor is a person, organization, or external
system that plays a role in one or more interactions with
your system. Actors are drawn as stick figures.

Associations. Associations between actors and use
cases are indicated by solid lines. An association exists
whenever an actor is involved with an interaction
described by a use case.
Example of Use Case Diagram
registration
student
updating
grades
output
generating
faculty
Use cases diagram
Transfer-data use case

A use case in the MHC-PMS
Tabular description of the
‘Transfer data’ use-case
MHC-PMS: Transfer data
Actors
Medical receptionist, patient records system (PRS)
Description
Data
A receptionist may transfer data from the MHC-PMS to a
general patient record database that is maintained by a
health authority. The information transferred may either
be updated personal information (address, phone
number, etc.) or a summary of the patient’s diagnosis
and treatment.
Patient’s personal information, treatment summary
Stimulus
User command issued by medical receptionist
Response
Confirmation that PRS has been updated
Comments
The receptionist must have appropriate security
permissions to access the patient information and the
PRS.
involving the role ‘Medical
Receptionist’
Use cases diagram
Use Case Diagram - University System
URS
add member
system
user
del member
add subject
academic
del subject
assg subject
unass subject
enrol subject
student
unenrol subject
Use Case Diagram for Student Assessment
Management System
Grade system
Record
grades
Student
View grades
Teacher
Distribute
Report cards
Create report
cards
Printing administrator
Example: video store system
Actor: Customer
- What tasks does the actor want the system to perform?
-
Find movie to rent, rent tape, return tape, reserve
tape
- What information must the actor provide to the system?
-
Name, address, membership#, film name
- Are there events that the actor must tell system about?
-
Change of address
- Does actor need to be informed when something happens?
-
Reserved tape is ready to be rented
- Does actor help initialize or shut down the system
-
no
Example: video store system
Resulting use cases:
» Customer joins and provides contact information
including name, address, phone#, credit
information, spouse and kids
» Customer browses system looking for a tape to
rent
» Customer comes to store looking for a specific
tape to rent
» Customer rents a tape
» Customer returns a tape
» Customer reserves a tape
» Customer is contacted when a reserved tape is
ready
Note: simple phrases, without much details initially.
ACTORS
USE CASE
C lu b M e m b e r
In itia te s
S u b m it P ro m o tio n O rd e r
S u b m it R e g u la r O rd e r
P o te n tia l M e m b e r
In itia te s
S u b m it N e w S u b scrip tio n
P a st M e m b e r
In itia te s
S u b m it S u b scrip tio n R e n e w a l
M e m b e rsh ip S e rv ice s D e p t.
In itia te s
R e q u e st M e m b e rsh ip R e p o rts
M a rk e tin g D e p a rtm e n t
In itia te s
C re a te N e w M o n th ly P ro m o tio n
C re a te N e w S e a so n a l P ro m o tio n
C re a te N e w S u b scrip tio n P ro g ra m
R e q u e st P ro m o tio n R e p o rts
R e q u e st S a le s R e p o rts
In itia te s
S e n d N e w S u b scrip tio n O ffe r
S e n d C lu b P ro m o tio n
S e n d S u b scrip tio n R e n e w a l
M e m b e rsh ip S e rv ice s S y ste m
Club
Member
Member Services
Context Model
Club promotion
Promotion order
Subscription Offer
New Subscription
regular order
Past
Member
Subscription renewal
offer
Potential
Member
Member credit status
Subscription renewal
Order to be filled
A/C Receivable
DB
Membership
Reports
Warehouse
Member Services Dept.
Marketing Dept.
Sequence diagrams




Sequence diagrams are part of the UML and are used
to model the interactions between the actors and the
objects within a system.
A sequence diagram shows the sequence of
interactions that take place during a particular use
case or use case instance.
The objects and actors involved are listed along the
top of the diagram, with a dotted line drawn
vertically from these.
Interactions between objects are indicated by
annotated arrows.
Sequence diagram for View
patient information
Sequence diagram for Transfer
Data
Classes and associations in the
MHC-PMS
A generalization hierarchy
A generalization hierarchy with
added detail
State machine models




These model the behaviour of the system in response to
external and internal events.
They show the system’s responses to stimuli so are often used
for modelling real-time systems.
State machine models show system states as nodes and events
as arcs between these nodes. When an event occurs, the
system moves from one state to another.
Statecharts are an integral part of the UML and are used to
represent state machine models.
State diagram of a microwave
oven
Weather system description
A weather data collection system is required to generate
weather maps on a regular basis using data collected from
remote, unattended weather stations and other data sources
such as weather observers, balloons and satellites. Weather
stations transmit their data to the area computer in response
to a request from that machine.
The area computer validates the collected data and
integrates it with the data from different sources. The
integrated data is archived and, using data from this archive
and a digitised map database a set of local weather maps is
created. Maps may be printed for distribution on a specialpurpose map printer or may be displayed in a number of
different formats.
Weather station description
A weather station is a package of software controlled
instruments which collects data, performs some data
processing and transmits this data for further processing.
The instruments include air and ground thermometers, an
anemometer, a wind vane, a barometer and a rain gauge.
Data is collected every five minutes.
When a command is issued to transmit the weather data, the
weather station processes and summarises the collected data.
The summarised data is transmitted to the mapping
computer when a request is received.
Subsystems in the weather mapping system
« s u b sy st e m»
Da ta co lle c tio n
« s u b sy st e m »
Da ta d isp la y
O b s e rve r
S a t e llite
Co mms
W e a th e r
s ta t io n
B a llo o n
Ma p
d is p la y
Ma p
p rin t e r
Ma p
« s u b sy st e m»
Da ta a rch iv in g
« s u b sy st e m»
Da ta p ro ce s sin g
Da ta
ch e ckin g
Us e r
in te rf a ce
Da ta
in t e g ra tio n
Da ta
s to ra g e
Ma p s to re
Da ta st o re
Use-cases for the weather station
S t a rtu p
S h u t d o wn
Re p o rt
Ca lib ra te
Te s t
Use-case description
S ys tem
We a th e r s tati on
U se-c ase
R e por t
Ac tor s
We a th e r da ta co ll ec ti on sys tem, W e ather stati on
Da ta
T he w e ather sta tion send s a sum ma ry of t he w ea the r da ta t ha t h a s been
co ll ec ted f ro m t he instrum en ts in the co ll ec ti on pe riod t o the wea the r da ta
co ll ec ti on sy stem . The da ta sen t ar e the m ax im um mi nim um and ave rage
ground and air tem pe ratures , the m ax im um , m in im um and av e ra ge air
pres sur e s, the m ax im um , mi nim um a nd ave rage w ind speed s, the total
rainf a ll and th e w ind dire c tion as sam pl e d at 5 mi nu te in te rva ls .
S timulu s
T he w e ather da ta co ll ec ti on sys tem es ta bl is hes a mod em li nk w it h t he
wea the r s tati on and reque st s tran smi ss ion of the da ta.
Re sp on se
T he sum m a ris ed d a ta i s se nt to the wea the r da ta co lle cti on sys tem
Co m m e nts
We a th e r s tati on s a re usua ll y asked t o repo rt onc e pe r hou r but t his
frequ e ncy m ay dif fe r fr om one stati on t o the other and m ay be m od ified i n
future .
Weather station object classes

Ground thermometer, Anemometer, Barometer
•

Weather station
•

Application domain objects that are ‘hardware’ objects related to the
instruments in the system
The basic interface of the weather station to its environment. It
therefore reflects the interactions identified in the use-case model
Weather data
•
Encapsulates the summarised data from the instruments
Weather station object classes
W e a th e rD a ta
W e a th e rS ta ti on
id e n t ifie r
a irTe m p e ra t u re s
g ro u n d Te m p e ra t u re s
win d S p e e d s
win d Dire c tio n s
p re s su re s
ra in fa ll
re p o rt W e a t h e r ()
c a lib ra te (in st ru me n t s)
t e st ()
s ta rt u p (in s tru m e n ts )
s h u td o w n (in s tru m e n ts )
c o lle ct ()
su m ma ris e ()
G rou nd
the rm o m e te r
An e m o m e te r
Ba rom e te r
te m p e ra t u re
win d S p e e d
win d Dire c tio n
p re s su re
h e ig h t
te s t ()
c a lib ra t e ()
te s t ()
t e st ()
c a lib ra t e ()
Weather station subsystems
« s u b sy st e m»
I n te rf a ce
« s u b sy st e m »
Da ta co lle c tio n
Co mms Co n tro lle r
W e a t h e rS ta t io n
W e a t h e rDa t a
In s tru m e n t
S t a tu s
« s u b sy st e m»
I n st ru me n t s
A ir
th e rmo me te r
Ra in G a u g e
A n e m o me t e r
G ro u n d
th e rmo me te r
B a ro m e te r
W in d Va n e
Sequence models

Sequence models show the sequence of object
interactions that take place
•
•
•
•
Objects are arranged horizontally across the top
Time is represented vertically so models are read top to bottom
Interactions are represented by labelled arrows, Different styles of
arrow represent different types of interaction
A thin rectangle in an object lifeline represents the time when the
object is the controlling object in the system
Data collection sequence
Statecharts

Show how objects respond to different service
requests and the state transitions triggered by
these requests
•
•
•
•
•
If object state is Shutdown then it responds to a Startup()
message
In the waiting state the object is waiting for further
messages
If reportWeather () then system moves to summarising
state
If calibrate () the system moves to a calibrating state
A collecting state is entered when a clock signal is
received
State Diagram
returned()
not
borrowable
returned()
borrowable
borrowed()[last copy]
guard expression
borrowed()[not last copy]
State diagram for class Book
Weather station state diagram
O pe rat ion
cali brat e ()
C ali brat in g
cali brat io n OK
S h ut do wn
s tartu p ()
t es t ()
W ait in g
Test in g
t ran sm i ss i on do ne
s hu td ow n ()
t es t com p let e
T rans m it ti ng
clo ck
col lect io n
d on e
repo rtW eath er ()
S u m m ari s in g
C o ll ect in g
weat her su m m ary
com p let e
Example



International Alexandria University wants to install a
new student self-service system for student
enrollment, registration and payment.
A local bank called YMOM (Your Money is Our
Money) Bank Corp. will join Alexandria to create a
flexible bank account that can be used to
conveniently pay for courses as well as other oncampus expenses.
Alexandria will issue a new campus-wide Id card that
combines all the features of a bank ATM card as well
as a University ID card.
The course registration system is available as a webbased application. It is part of the joint application
maintained by ALEXU and YMOM.
The following are some of the business rules:

Every course has a cost.

Every course has an optional list of prerequisites, in the
form a list of courses.

A student must have an established Alexu student
enrollment record in the system, with an ID card and
YMOM account before registering for a course.

A student will have a list of courses, described with the
quarter they took the course, payment status and their
grade, if appropriate.








A student can register for a course without having the money to
pay for it in their YMOM account, as long as all prior courses
have been paid for.
Registration for a specific course is only possible during a
defined window of time, 3 week before the end of the current
quarter and 2 weeks into the beginning of the next quarter.
A student will not see a grade for a course unless they have
registered for the course and have paid for it in full.
A professor can submit a grade for a course for a student.
A student may declare a Major and a Minor, each one implying
a list of required and optional courses.
A student can drop a course they have registered for and the
money will be automatically made available in their YMOM
account.
The students can access the system via their own PC accessing
the web or via a network of YMOM ATMs






The number on their student id/ATM card is the user id
for the application and the ATM PIN number is the
password for the site.
They can:
1. See their current transcripts,
2. Register for a course in the next quarter.
When they register for a course, they will be presented
with the set of courses that match their Major or Minor
selections, the current courses offered and the courses
with which they have fulfilled the prerequisites.
3. Transfer funds from the YMOM account to pay for
a course.




The University is a progressive IT
customer. They want to roll out system
functionality as fast as it can be made available.
They want to engage student-lead focus groups to
assess the quality and acceptance of the
application.
They are concerned with the security and
integration of the application with the YMOM
systems.
The system development is not with out risks
however, as CS305 has very limited experience
with the kind of networking complexity and
Questions



What life cycle model would you choose for this
project? What life cycle would be the least
appropriate? Explain your choice
Identify the class name, the class responsibilities
and collaborators (CRC) for each class involved in
the registration of a student in a course via the web
site
Produce a UML class diagram specifying all the
classes involved
Questions

Produce a UML state diagram that defines the states
and transitions for the object (or objects) involved in
implementing the rules that control the registration,
grade submission, grade visibility, payment and
dropping of a course for a student
Quize



Why is the pure Waterfall model of software
development not recommended for large-sale
software projects
You have been asked to lead a five-person software
development team that will implement a small but
safety critical software package. Which software
process would you select and why?
Describe the difference between functional and nonfunctional requirements. Give two examples of each





A bank continues to use software developed in 1975 for its core
operations. This software was programmed using a language
which is seldom used today, and over the years the software has
become poorly documented and badly structured as maintenance
tasks have been undertaken.
The bank’s IT director has asked you to write a report on the
ongoing challenges of this software. Within your report you
should include the following:
(a) A discussion of the types of maintenance that are required for
such software.
(b) A discussion of the challenges faced by the bank in
maintaining this software as it currently stands.
(c) A discussion of options for re-engineering the bank's software,
including the risks and benefits of such an approach.



You are required to develop a risk analysis for a
software system for a real time controller for a
nuclear reactor.
A) List five risks that could significantly affect
the project and mitigation techniques.
B) Estimate the cost of the project. Provide
details


A local bank has given you the requirements
specification for a system to manage customer
accounts. In particular, the specification identifies
the data, the processes, and the user interface
expected. The data include name, address, current
balance, and the transaction type, and amount.
Likewise, the processes include the creation, update,
and deletion of customer accounts, and deposit and
withdrawal transactions keyed in at a terminal.
Based on the information given, use an appropriate
design