ECE 473 573 Class Notes

1
ECE 473 / 573Class Notes

• Introduction to the Unified Software Development
  Process and OO Analysis

2
The Unified Software Development Process
- The Unified Process is a software development
process which has been defined in
continuation of the definition of Unified
Modeling Language (UML) as a standard for
modeling object oriented software. - It has
grown out of the Objectory use case driven design
process initially defined by Jacobson
. Sources 1     Booch, G., Rumbaugh, J., and
Jacobson, I., The Unified
Modeling Language Users Guide, Addison Wesley,
1999 2 Jacobson, I.,
Christenson, M., Jonsson, P. and Övergaard, G.,
Object Oriented Software
Engineering, Addison Wesley, 1992.
3 Jacobson, I., Booch,
G., and Rumbaugh, J.,
The Unified Software Development Process, Addison
Wesley, 1999.
3
Unified Process
The use case model is supposed to define the
requirements posed on the system and is intended
to drive the whole development process.
4
Unified Process (contd)

•          The analysis model is specified as an
  initial object structure in the form of UML class
  and object diagrams which is able to realize the
  behavior specified in the use cases.
•          The design model is the software
  blueprint of the system developed from the
  analysis model to fulfill the use case
  requirements. It defines in detail the class and
  object structures as well as their interactions
  and dynamic behavior to realize the use cases. It
  also has to consider all the non-functional
  requirements posed on the system.
•          The implementation model is the
  realization of the system in form of program
  code.
•          The deployment model represents the
  architecture of the execution environment to run
  the software.
•          The test model consists of the test
  cases to verify that the system fulfills all the
  requirements. The test cases can directly be
  derived from the use case descriptions.

5
Unified Process (contd)
Besides use case model, Architectures play a
dominant role in the Unified Process. An
architecture embodies the most significant
static and dynamic aspects of a the system.
Component-based The software system is built
up of components which have well defined
interfaces. Reusable building blocks should be
identified during the design process.
6
Use Case Model
   the actors, i.e., all the components which
are outside the system but interact with it
in some form,    the system boundary through
which the actors communicate with the system, and
the use cases that describe the interaction
of the actors with the system in fulfillment
of a particular task. They do this by adopting a
Black Box view, in that the inputs to and
responses from the system are defined, but the
interior of the system is concealed. In the
Unified Process the input/output behavior
captured in the use cases is event-based.
Use case as input/output description between
actors and the system
7
Analysis Model
- The analysis model is intended to define a
first structure of the system to be designed in
the form of a class and/or an object diagram.
The analysis model, therefore, represents an
important step in the development process
because it gives the system its initial structure
which is subject to further refinement in later
development steps. - Guidelines for discovering
objects and classes for the analysis model.
Domain representation or conceptual modeling is
derived from the idea that objects in reality
can also be found in the software system. A
textual analysis of the problem specification can
be used to filter out objects together with
relevant attributes, associations, and
operations.
8
Analysis Model (contd)
Unified Process suggests distinguishing three
types of objects   Interface objects
mediate the communication with the actors.
They directly correspond to the
actor/system interfaces.   Entity objects
are objects to hold information. They
often correspond to the objects in reality and
can be found by conceptual domain
modeling as discussed above. Control
objects are those objects which coordinate and
allocate work between the different
objects in fulfillment of a particular
use case.
9
Limitations of the Unified Process
It has several deficiencies in relation to
embedded systems that are of most interest to
engineering applications        How to find
use cases The Unified Process does not give
useful guidelines how to find relevant use
cases. It recommends that user sessions are use
cases. This however is not practical for
embedded systems where actors continually
interact with the system.     How to find
the objects Conceptual modeling inappropriate
for complex system analysis and design.
First of all, textual problem specifications for
complex domains are either not available at
all or much too voluminous to lend themselves
to textual analysis. A direct automatic
derivation of objects types with data structure
and behavior from textual descriptions is not
practical. In what follows we suggest a
procedure for identifying objects combining
several approaches in the literature.   
What are useful architectures for analysis
Although the Unified Process stresses the
importance of architectures in the development
process, it does not state what useful
architecture for analysis models are, nor how
such can be found.
10
Procedure for OO Analysis
Write system/software requirements description
Identify candidate objects of the problem
domain (nouns in requirements description)
Categorize objects
Down select objects into classes
Create CRC model
Iterate until all requirements have been
accounted for!
CRC Class Responsibility Collaborator
11
Categories of Objects

• External Entities
• Things
• Occurrences or events
• Roles
• Organizational Units
• Places
• Computational Entities (structure)

12
Down Selection Criteria

• Does this object encapsulate state information
  essential to meet the requirements?
• Does this object offer services needed to meet
  the requirements?
• Is this object simple enough to be considered as
  an attribute of a class?
• Do these objects have common attributes and
  operations to form a class?

13
Categorization and Selection Table
14
Example of Categorization and Selection Table
15
Example System Requirements Descriptions
FactoryWatchTM software enables a plant
supervisor to install a system to monitor the
activities of people and machines in a
non-intrusive manner. It requires placement of
video cameras in various locations of the plant
in which activities are to be monitored. The
software is installed on a computer near a camera
and performs interpretation of the image output
streams. It uses the quantization principle to
detect major changes in the images being
generated and only sends information to a central
database when such changes occur. The system
operates in both real-time and non-real-time
modes. In real-time mode, the system can alert
the plant supervisor to an abnormal situation in
production who can send out a technician to
correct the problem. In non-real-time mode, the
supervisor can examine the record of images from
one or more cameras in the database to try to
understand how a problem has arisen and how it
might be prevented in the future.
16
CRC Model
Create Class-Responsibility-Collaborator (CRC)
model
Identify responsibilities (operations to be
carried out by the object requested by others or
itself)
Identify collaborators (other objects it
interacts with directly)
Class name
Responsibilities (start with verbs from
requirements description)
Collaborators
17
Camera Class
Camera

• Collaborators
• Quantizer
• Camera location
• Message

• Responsibilities
• Take images from factory floor at some time
  interval with some specified resolution
• Send images to designated targets (e.g.,
  quantizer)

18
(No Transcript)
19
UML Diagrams and How to use them
20
Why is UML important?
 
UML has emerged a blueprint for software
development process.
 
21
UML Modeling Diagrams

• At the center of the UML are its eight different
  kinds of modeling diagrams.
• Use case diagrams
• Class diagrams
• Sequence diagrams
• Collaboration diagrams
• Statechart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams

22
UML applicable to OO problem solving

Anyone interested in learning UML must be
familiar with the underlying tenet of
object-oriented problem solving -- it all begins
with the construction of a model. A model is an
abstraction of the underlying problem. The
domain is the actual world from which the problem
comes. Models consist of objects that interact
by sending each other messages. Think of an
object as "alive." Objects have things they know
(attributes) and things they can do (behaviors or
operations). The values of an object's attributes
determine its state. Classes are the
"blueprints" for objects. A class wraps
attributes (data) and behaviors (methods or
functions) into a single distinct entity.
Objects are instances of classes.
23
Use Case Diagrams
Use case diagrams describe what a system does
from the standpoint of an external observer. The
emphasis is on what a system does rather than
how. Use case diagrams are closely connected to
scenarios. A scenario is an example of what
happens when someone interacts with the system.
Here is a scenario for a medical clinic. "A
patient calls the clinic to make an appointment
for a yearly checkup. The receptionist finds the
nearest empty time slot in the appointment book
and schedules the appointment for that time
slot. A use case is a summary of scenarios for
a single task or goal. An actor is who or what
initiates the events involved in that task.
Actors are simply roles that people or objects
play. The picture below is a Make Appointment use
case for the medical clinic. The actor is a
Patient. The connection between actor and use
case is a communication association (or
communication for short).
24
Use Case Diagram Example make an appointment
25
The areas where Use Case Diagrams are useful.

• determining features (requirements). New use
  cases often generate new requirements as the
  system is analyzed and the design takes shape.
• communicating with clients. Their notational
  simplicity makes use case diagrams a good way for
  developers to communicate with clients.
• generating test cases. The collection of
  scenarios for a use case may suggest a suite of
  test cases for those scenarios.

26
Expansion of Use Case Diagrams
UML use case features            system
boundaries          generalizations         
includes          extensions
27
(No Transcript)
28
Class Diagram
A Class diagram gives an overview of a system by
showing its classes and the relationships among
them. Class diagrams are static -- they display
what interacts but not what happens when they do
interact.
29
Class Diagram

• class diagram has three kinds of relationships.
• association -- a relationship between instances
  of the two classes. There is an association
  between two classes if an instance of one class
  must know about the other in order to perform its
  work. In a diagram, an association is a link
  connecting two classes.
• aggregation -- an association in which one class
  belongs to a collection. An aggregation has a
  diamond end pointing to the part containing the
  whole. In our diagram, Order has a collection of
  OrderDetails.
• generalization -- an inheritance link indicating
  one class is a superclass of the other. A
  generalization has a triangle pointing to the
  superclass. Payment is a superclass of Cash,
  Check, and Credit.

30
Class Diagrams
A navigability arrow on an association shows
which direction the association can be traversed
or queried. An OrderDetail can be queried about
its Item, but not the other way around. The arrow
also lets you know who "owns" the association's
implementation in this case, OrderDetail has an
Item. Associations with no navigability arrows
are bi-directional. The multiplicity of an
association end is the number of possible
instances of the class associated with a single
instance of the other end. Multiplicities are
single numbers or ranges of numbers. In our
example, there can be only one Customer for each
Order, but a Customer can have any number of
Orders. This table gives the most common
multiplicities.
Every class diagram has classes, associations,
and multiplicities. Navigability and roles are
optional items placed in a diagram to provide
clarity.
31
Packages and Objects
To organize complex class diagrams, you can group
classes into packages. A package is a collection
of logically related UML elements. Packages
appear as rectangles with small tabs at the top.
The package name is on the tab or inside the
rectangle. The dotted arrows are dependencies.
One package depends on another if changes in the
other could possibly force changes in the first.
32
Packages and Objects (contd)
Object diagrams are special kinds of class
diagrams, showing instances instead of classes.
They are useful for explaining small pieces with
complicated relationships, especially recursive
relationships.
The object diagram below instantiates the class
diagram, replacing it by a concrete example.
33
Sequence Diagrams
Class and object diagrams are static model views.
Interaction diagrams are dynamic. They describe
how objects collaborate. A sequence diagram is an
interaction diagram that details how operations
are carried out -- what messages are sent and
when. Sequence diagrams are organized according
to time. The time progresses as you go down the
page. The objects involved in the operation are
listed from left to right according to when they
take part in the message sequence.
34
Collaboration Diagrams
Collaboration diagrams are also interaction
diagrams. They convey the same information as
sequence diagrams, but they focus on object roles
instead of the times that messages are sent. In a
sequence diagram, object roles are the vertices
and messages are the connecting links.
35
Statechart Diagrams
Objects have behaviors and state. The state of an
object depends on its current activity or
condition. A statechart diagram shows the
possible states of the object and the transitions
that cause a change in state.
36
Activity Diagrams
An activity diagram is essentially a fancy
flowchart. Activity diagrams and statechart
diagrams are related. While a statechart
diagram focuses attention on an object
undergoing a process (or on a process as an
object), an activity diagram focuses on the
flow of activities involved in a single process.
The activity diagram shows the how those
activities depend on one another.
37
Component and Deployment Diagrmas
A component is a code module. Component diagrams
are physical analogs of class diagram. Deployment
diagrams show the physical configurations of
software and hardware.