Structural ModelingDr. Ardeshir BadrObjectives• .docx

Structural Modeling
Dr. Ardeshir Badr
Objectives
• Understand the rules and style guidelines, and processes used
for
creating class diagrams and object diagrams
• Be able to create class diagrams, and object diagrams
• Understand the relationship among the structural models
• Understand the relationship between the structural and
functional
models
• A structural model defines the structure of the objects (people,
places,
things and how they are related) that support the business
processes of
an organization
• Structural modeling supports the creation of a static view of
the system
Structural Modeling

Analysis Workflow
Conceptual model: How the
objects are stored, created,
or manipulated (Logical
organization of the objects)
Design Workflow
Design model: How the objects
will be organized in databases
and software
• In analysis phase, the structural model contains classes,
attributes, operations, and the
relationships, however they do not represent software
components or classes in an object oriented
programming language. These initial classes are refined into
programming level objects at later
stages
• The structural models in analysis workflow should represent
the responsibilities of each class and
the collaborations among classes
• Elements of a structural model:
• Classes: A template used for creating specific instances or
objects. All objects of a given class are
identical in structure and behavior, but can contain different
data in their attributes. We have two class
types:
• Concrete: Used to create objects
• Abstract: No objects are created from them, but are useful

abstractions
• Attributes: Information relevant to the description of a class,
for example, employee class has name as an attribute
• Operations: Defines the behavior of a class, or actions to
which the instances of a class are capable of responding
Elements of Structural Models
• Relationships are in three data abstraction mechanism
categories:
• Generalization relationships: A superclass that contains the
basic attributes and operations will
be used in several subclasses. The subclasses inherit the
attributes and operations of their
superclass and can also contain attributes and operations unique
to them (a-kind-of). For
example, a pilot class (subclass) and a professor (subclass) class
can be generalized into a person
class (superclass)
• Aggregation relationships: Relate parts to the whole or a-part-
of relationship, for example, the
relationship between an engine and a car is: an engine is a part
of a car
• Association relationships: Relationships that do not fit into
generalization or aggregation, for
example, a patient schedules an appointment. The patient is not
a part of an appointment and
patient is not a kind of appointment. We can say there is an
association relationship between
patient and an appointment

Elements of Structural Models - Relationships
Class types and generalization relationship
Person
Doctor Patient
General Practitioner Specialist
Superclass for
Doctor and
Patient
Superclass for
General
Practitioner and
Specialist
Abstract
class
Abstract
class
Concrete
class
Concrete
class

Concrete
class
Classes are arranged in a hierarchy of
superclasses or general, and
subclasses or specific classes
Subclasses inherit the appropriate
attributes and methods from the
superclasses above them
Concrete classes are the ones that
have instances
Classes that produce no instance and
are used as templates for other more
specific classes are called abstract
classes
• To identify objects for structural model:
• Textual analysis
• Brainstorming
• Common objects lists
• Patterns
Object Identification
• Creates an initial cut of a structural model

• Review use case diagrams and use case descriptions to
identify potential objects,
attributes, operations, and relationships
• Basic guidelines:
• A noun is an indicative of a class or objects
• An adjective implies an attribute of an object
• A doing verb or transitive verb implies an operation
• A being verb or having verb implies a relationship
Object Identification – Textual Analysis
Campus Housing Services Example:
From the use case diagrams and use case descriptions we can
identify the following:
• Objects are apartment and apartment owner
• Attributes of apartment are: location, number of bedrooms,
monthly rent, and the distance from the
campus
• Attributes of owner are: name, address, phone number, email
• The relationship is: one to many relationship between an
apartment owner and an apartment
• Operations are Add Apartment and Delete Apartment
Use Case Diagram for Campus Example
Use Case Descriptions for Campus Example
• Is a discovery technique

• Brainstorming process:
• A set of individuals sitting around a table suggest potential
classes
• A facilitator asks the set of individuals to address a specific
question
• For example facilitator asks the analysts and users to think
about their experience with making Doctor
appointments and to identify candidate classes based on their
past experience
• The analysts and users might come up with classes name, for
example, Doctor, Patient, Nurse,
Receptionist, Health Insurance. Then they can narrow down the
number of classes, and have another
brainstorming on identifying the attributes, operations and
relationships
• In brainstorming we do not use the functional models
developed before (use cases, use case
descriptions or activity diagrams)
• Brainstorming Guidelines:
• Suggestions should be taken seriously
• All participants should be thinking fast and furiously
• Facilitator must mange the fast and furious thinking process to
avoid chaotic sessions
• A round robin approach is recommended
• Facilitator should use humor to break the ice
Object Identification – Brainstorming
• A list of objects common to the business domain:

• Physical or tangible things, for example, books, desks, chairs,
office equipment
• Incidents: events that occur in the business domain, for
example, meetings, flights,
performances
• Roles: reviewing the use case can identify the roles, for
example, student, apartment owner
• Interaction: a transaction that takes place in business domain,
for example, sales transaction
• Places, containers, organizations
• Processes sometimes contain information in them
• Library of reusable objects, for example, Common Open
Source Medical Objects
Object Identification – Common Object List
• A pattern is a useful group of collaborating classes that
provide a solution to commonly occurring
problems, which makes them reusable
• Using patterns from different sources enable the development
team to create more complete
and robust models of the problem domain
• Useful patterns that are already developed:
• Accounting

• Actor-Role
• Assembly-Part
• Container-Content
• Contract
• Document
• Employment
• Geographic Locations
• Material Requirements Planning
• Organization and Party
• Trading
Object Identification – Patterns
Object Identification – Patterns
Application of Patterns to Making a Doctor Appointment
Elements of a class Diagram
Class: Represents a kind

of person, place, or
thing about which the
system should capture
and store information
Attribute: Represents
properties that
describe the state of
an object
Operation: Represents
the actions or functions
a class can perform. Can
be constructor, query, or
update types
Association: Represents a
relationship between multiple
classes or a class and itself, and
can have multiplicity which
represents the minimum and
maximum times a class instance
can be associated with the
related class instance
Generalization:
Represents a kind
of relationship
between multiple
classes
Aggregation: Represents a
logical a-part-of relationship
between multiple classes or a
class and itself

Composition: Represents a
physical a-part-of relationship
between multiple classes or a
class and itself
Class Diagram for Campus Housing Service
Object Oriented Programming in Python
#Create a class for Employee with attribute first_name,
last_name, salary
class Employee:
def __init__(self, first_name, last_name, salary):
self.first_name = first_name
self.last_name = last_name
self.salary = salary
self.email = first_name + '.' + last_name + '@education.com'
employee1 = Employee('Ardeshir','Badr',50000)
employee2 = Employee('Adam', 'Adrian', 60000)
print(employee1.email)
#Create a class for Employee with attribute first_name,
last_name, salary
#Add a method to print the full name

class Employee:
def full_name(self):
return self.first_name + ' ' + self.last_name
print(employee1.full_name())
print(Employee.full_name(employee2))
#Add a class variable raise_amount and a method apply_raise()
to increase the salary. Class variables stay the same for all
#instances, and should be accessed by self.
class Employee:
raise_amount = 1.04

def apply_raise(self):
self.salary = int(self.salary * self.raise_amount)
print(employee1.salary)
employee1.apply_raise()
print(employee1.salary)
#Use instance_name.__dict__ to get all information on
attributes of an object
class Employee:
raise_amount = 1.04

print(employee1.__dict__)
{'first_name': 'Ardeshir', 'last_name': 'Badr', 'salary': 50000,
'email': '[email protected]'}
#Use class_name.__dict__ to get all information on attributes of
a class
class Employee:
raise_amount = 1.04
print(Employee.__dict__)
{'__module__': '__main__', 'raise_amount': 1.04, '__init__':
<function Employee.__init__ at 0x000002E60D63EE18>,
'full_name': <function

Employee.full_name at 0x000002E60D63EEA0>, 'apply_raise':
<function Employee.apply_raise at 0x000002E60D63EF28>,
'__dict__': <attribute
'__dict__' of 'Employee' objects>, '__weakref__': <attribute
'__weakref__' of 'Employee' objects>, '__doc__': None}
#The class variable num_employees can be incremented as more
employees are created
class Employee:
num_employees = 0
raise_amount = 1.04
Employee.num_employees += 1
print(Employee.num_employees)
print(Employee.num_employees)
0

2
#Class methods are indicated by @classmethod and can be used
for setting class variables. Class variables are the same for all
instances of that class.
class Employee:
num_employees = 0
raise_amount = 1.04
@classmethod
def set_raise_amount(cls, amount):
cls.raise_amount = amount
Employee.set_raise_amount(1.07)

print(Employee.raise_amount)
print(employee1.raise_amount)
print(employee2.raise_amount)
1.07
1.07
1.07
#Static methods act like functions, they do not have any
dependencies on the class, but have some logical relationship
with the class, for example, no self needed as first arg.
class Employee:
num_employees = 0
raise_amount = 1.04
@classmethod
def set_raise_amount(cls, amount):

cls.raise_amount = amount
@staticmethod
def is_working_day(day):
if day.weekday() == 5 or day.weekday() == 6:
return False
return True
import datetime
my_date = datetime.date(2018,4,30)
print(Employee.is_working_day(my_date)
True
#Inheritance allows us to inherit attributes and methods from
the parent class. We can create sub classes with all attributes
# and methods of parent class and add new attributes and
methods without affecting the parent class. Now we want to
# create/inherit developers and managers from Employee
class Developer(Employee):
pass
developer_1 = Developer('Adrian','Badr', 67000)
developer_2 = Developer('Adam','Badr', 78000)
print(developer_1.email)
[email protected]

#Now if we print the help on Developer class, we will see the
details of inherited attributes and methods
print(help(Developer))
class Developer(Employee)
| Method resolution order:
| Developer
| Employee
| builtins.object
|
| Methods inherited from Employee:
|
| __init__(self, first_name, last_name, salary)
| Initialize self. See help(type(self)) for accurate signature.
|
| apply_raise(self)
|
| full_name(self)
|
| ----------------------------------------------------------------------
| Class methods inherited from Employee:
|
| set_raise_amount(amount) from builtins.type
|
| ----------------------------------------------------------------------
| Static methods inherited from Employee:
|
| is_working_day(day)
| ----------------------------------------------------------------------
| Data descriptors inherited from Employee:
|

| __dict__
| dictionary for instance variables (if defined)
|
| __weakref__
| list of weak references to the object (if defined)
|
| ----------------------------------------------------------------------
| Data and other attributes inherited from Employee:
|
| num_employees = 2
|
| raise_amount = 1.04
#Changes to sub class does not affect parent class
#To add a new parameter to dev constructor, we create a new
__init__ and use supper().__init__
class Developer(Employee):
raise_amt = 1.10
def __init__(self, first_name, last_name, salary,
programming_lang):
super().__init__(first_name, last_name, salary)
self.programmimg_lang = programming_lang
developer_1 = Developer('Adrian','Badr', 67000, 'Python')
developer_2 = Developer('Adam','Badr', 78000, 'Java')
print(developer_1.email)
print(developer_1.programmimg_lang)
[email protected]

Python
#We inherit a new class from employee called Manager. We add
a new attribute that has the list of employees that manager
manages
class Manager(Employee):
employees=None):
if employees is None:
self.employees = []
else:
self.employees = employees
def add_employee(self, employee):
if employee not in self.employees:
self.employees.append(employee)
def remove_employee(self, employee):
if employee in self.employees:
self.employees.remove(employee)
def print_employees(self):
for emp in self.employees:
print('--->', emp.full_name())

manager_1 = Manager('Marie', 'Well', 98000, [developer_1])
print(manager_1.email)
print(manager_1.print_employees())
[email protected]
---> Adrian Badr
#Adding a new employee to the list of employees managed by
manager 1
employees=None):
self.employees = []
else:

manager_1.add_employee(developer_2)
print(manager_1.print_employees()) ---> Adrian Badr
---> Adam Badr
#We can use isinstance to check if an instance is inherited from
a class
employees=None):
self.employees = []
else:

print(isinstance(manager_1, Manager)) True
#We can use issubclass to verify if a class is a subclass of
another class
employees=None):
self.employees = []
else:

print(issubclass(Manager, Developer)) False
• Develop a class diagram for graduate and undergraduate
students
billing system. The model calculates the tuition a student has to
pay
based on tuition per credit hour, the course taken. The tuition
per
credit hour depends on whether the student is a graduate or
undergraduate. The tuition per credit hour for all graduate
students is
$300.00 and for all under graduate students is $250.00.
Activity

taken
to next class)
oject
Before next class
Project Management
Dr. Ardeshir Badr
Objectives
• Understand the importance of IT alignment with business
needs
• Understand how to assess technical, economic, and
organizational
feasibility
• Become familiar with work breakdown structures, Gantt
charts, and

network diagrams, and how to create a project plan, and how to
staff
a project
• Become familiar with use case driven effort estimation
• Understand how to manage the scope, refine the estimation,
and
mange the risk of a project
• Understand how the environment and infrastructure workflows
interact with the project management workflow
• Project: A set of activities with starting and ending times
meant to
create an information system that brings added value to a
business
• Project Management: Is the process of planning and
controlling/monitoring the development of an information
system
that meets the requirements within a specified time frame, and
at a
minimum cost
• Project manager: After years of experience as an analyst, one
can
become a project manager, who is responsible for managing and
coordinating hundreds of tasks and roles
Introduction

Project Management Workflow (Unified Process)
Project
Identification
Feasibility
Analysis
Project
Selection
Project Effort
Estimation
Workplan
Creation and
Management
Staffing Project
Environment
and
Infrastructure
Management
• Business needs:
• Supporting a new marketing campaign, reaching out to new
type of customers, or improving interactions with
suppliers
• Drop in market share, poor customer service level, increased

competition
• Enabling new business initiatives and strategies
• Emerging technologies
• A project is identified when someone in the organization
identifies a business need to build a system. The project
identifier
can originate from one or more of the following in an
organization:
• A business unit
• IT department
• Steering committee charged with identifying new business
opportunities
• Recommendations made by an external consultant company
• Project sponsor: Is someone, usually from a business function
or IT, who recognizes the strong business need for a system
has an interest seeing the project succeed. The size and type of
project determines the kind of sponsorship needed; small
projects will have a single manager, while large projects might
need sponsorship from senior management
Project Identification
• Requirements: The features and capabilities an information

system
will contain
• Tangible value: Can be quantified and measured, for example,
10%
reduction in operation costs
• Intangible value: Hard to measure but important added value,
for
example, improved customer service
• After project sponsor identifies a project that meets the
business
needs and he/she can identify the system’s business
requirements
and values, then a project can be initiated
• Project initiation begins with system request
Project Identification
• A system request is a document that describes the business
reason for
building an information system and the value
(tangible/intangible) the
system is expected to provide
• The completed system request is submitted to approval
committee for
consideration
• Based on the information in system request, approval
committee
decides to investigate (feasibility study) the proposal or not

Project Identification – System Request
Project Name
Project Sponsor Name of project sponsor
Business need Short description of business need
Business requirements High level description of business
requirements
Business value Tangible and intangible values system can
provide
Issues or constraints Other relevant information concerning
stakeholders
• Feasibility study guides an organization in determining
whether or not to
proceed with a project
Feasibility Analysis
Technical Feasibility: Can the system be successfully designed,
developed, and deployed by IT department?
The answer is essentially a technical risk analysis. Risks
include:
• Lack of familiarity of users and analysts with the functional
area
• Familiarity with the technology; new technologies increase
risks
• Project size; larger projects preset more risks
• Technical compatibility; the lack of compatibility with the

existing systems increases risks
Economical Feasibility: Should we build the system? The
answer identifies the associated financial (costs and
benefits) risks with the project
Organizational Feasibility: How well the system will be
accepted by the users and incorporated into the
existing and ongoing operations? The answer needs to assess
the following factors:
• Strategic alignment; the greater the alignment the less risky
the project will be
• Stakeholders (person, group or organization that can affect or
be affected by a new system);
The feasibility study should be revised several times before
each iteration of the development process
• System request and feasibility study documents, are submitted
to
approval committee who decide whether to approve, decline, or
defer the project.
• The decision will also consider the portfolio of the projects of
an
organization
• Portfolio management takes into consideration the different
projects
that exist in an organization and tries to have a good mix of
projects
for the organization’s needs
• Projects can be classified based on size, cost, purpose, length,

risk,
scope, and return on investment (ROI)
Project Selection
• A task is a unit of work that will be performed by a member of
development team
• A task has name, start date, completion date, person assigned
to the
task, deliverable(s), status, priority, resource needed, estimated
time
to complete, and the actual time took to complete
• Work Breakdown Structure (WBS)
• Gantt Chart
• Network Diagram
Project Management Tools
Task
Identification
Tasks are organized
within a Work
Breakdown Structure
Gantt Chart
Network
Diagrams

• Work Breakdown Structure (WBS):
• High level tasks are first listed
• Each high level task is broken down into subtasks
• A WBS includes:
• Duration of task
• Status of task
• Task dependencies
• Approaches to organizing a WBS:
• By development phase
• By product
Project Management Tools – WBS
Project Management Tools – WBS
1. Inception
1.1 Feasibility Study
1.1.1 Technical
1.1.2 Economic
1.1.3 Organizational
2. Elaboration
3. Construction
4. Transition

1. Applets
1.1 Inception
1.2 Elaboration
1.3 Construction
1.4 Transition
2. Application Servers
2.1 Inception
2.2 Elaboration
2.3 Construction
2.4 Transition
3. Database Servers
Sample WBS based on development phase Sample WBS by
product
Task Number Task Name Duration
(weeks)
Dependency Status
1. Inception 4 In Progress
1.1 Feasibility Study 2 In Progress
1.1.1 Technical 1 In Progress
1.1.2 Economic 1 1.1.1 Open
Task Number Task Name Duration
(weeks)
Dependency Status

1. Applets 10 In Progress
1.1 Inception 4 In Progress
1.1.1 Feasibility Study 2 In Progress
1.1.2 Technical 1 1.1.1 Open
• A horizontal bar chart that shows the same task information as
WBS
in graphic way
Project Management Tools – Gantt Chart
• Project manager makes trade offs among:
• The functionality of the system
• The time to complete the project
• The cost of the project
• The project manager needs to estimate each of the above items
and
continuously assess how to roll out a project to meet the
requirements
• Estimation is the process of assigning the projected values for
time and
effort, and will evolve during the system development life cycle
• The estimate numbers can be taken from with similar tasks and
technology, or by experienced developers

• In Unified Process, which is use case driven, we use case
points (UCP)
approach to estimate the time required to develop a system
Project Effort Estimation
• Use case models:
• Actors: A role that a user of a system (can be also another
system) plays, for
example, administrator
• Use case: A major business process that system will perform
to benefit an actor, for
example, login use case logs in an administrator
• For use case points estimation, actors are classified as:
• Simple actors: Separate systems with which the current system
must communicate
through a well defined API
• Average actors: Separate systems that interact with the current
system using TCP/IP,
FTP, or HTTP protocols, or an external database using SQL
• Complex actors: The end users (human) communicating with
the system
• Similarly, a use case is classified as:
• Simple use case: It supports 1 to 3 transactions
• Average use case: It supports 4 to 7 transactions

• Complex use case: It supports 8 or more transactions
Project Effort Estimation – Use Case Points
• The number of actors in each category are entered into
unadjusted
actor weighting table, and we get unadjusted actor weight total
(UAW)
• The number of each type of use case is entered into unadjusted
use
case weighting table, and we get unadjusted use case weight
total
(UUCW)
• Then unadjusted use case points (UUCP) are obtained by
adding UAW
and UUCW
• Technical complexity factors (TCFs) and environmental
factors (EFs)
are used to adjust the use case point based estimations
• Using worksheet formulas we get an estimate of person hours
(see
templates)
Project Effort Estimation – Use Case Points
• Workplan is a dynamic schedule that records and keeps track
of all

the tasks that need to be accomplished during the project
• In a workplan for each task we have:
• Task name
• Completion date
• Assigned human resource
• Deliverables
• To create the list of tasks project manager can use a standard
list of
tasks from a methodology and then modify them accordingly,
and
add them to workplan
• We use Unified Process phases and workflows, and iterations
as a
stating point for to create a evolutionary WBS and iterative
workplan
(see template)
Workplan Creation and Management
• In Unified Process the development process is organized
around
phases, workflows, and iterations
• Evolutionary WBSs allows the creation of iterative workplan:
• They are organized in a standard manner across all projects by
workflows,
phases, and the specific tasks that are accomplished during an

individual
iteration
• They are created in an incremental and iterative manner
• They enable the comparison of the current project to the
previous projects
• The workflows are the major points listed in WBS, and then
each
workflow is decomposed along the phases of the Unified
Process.
Then each phase is decomposed along the tasks that are to be
completed to create deliverables associated with an individual
iteration contained in each phase (see template)
Workplan Creation and Management -
Evolutionary WBS and Iterative Workplan
• Scope creep: Schedule and cost overruns as a result of added
new
requirements
• To manage the scope, the following have been effective:
• Daily scrum meetings and product backlog in Scrum
• Timeboxing: The project becomes time oriented, i.e.,
delivering a product at a
certain date no matter what, even if we need to reduce
functionalities. RAD or agile
methodologies can use timeboxing (sprint)
• Managing Estimates: The preliminary estimate of time and
costs that are

produced during the inception, need to be refined as the project
progresses
• Managing Risks: The process of assessing and addressing the
risks that are
associated with developing a system
• Risk Assessment: A document that tracks the potential risks
with an
evaluation of likelihood of each risk and its potential impact on
the project
Workplan Creation and Management
• Staffing a project involves:
• Determining the number of persons that should be assigned to
the project
• Matching people’s skills with the need of the project
• Motivating the staff to meet the project’s objectives
• Minimizing conflicts
• Deliverables are:
• Staffing plan that lists roles and proposed reporting structure
• Project charter which describes the project objectives and
rules
• Technical skills: Beneficial when working on technical tasks

• Interpersonal skills: Beneficial when dealing/communicating
with business users,
senior management, executives
• The technical and interpersonal skills are taken into account
when a project
manager makes assignments
Staffing the Project
Staffing the Project – Reporting Structure
Project Manager
Functional Lead
Technical Lead
Business Analyst Business Analyst Developer DB Admin
• A project manager needs to motivate people for a successful
project
• Motivation has been found the number one influence on
people’s
performance
• Some ideas to motivate the personnel on a project:
• 20% time rule
• Giving small awards by an employee to another peer employee
• A day on which an employee can work on anything

• Employees should be paid sufficiently
• Project manager should sit in shared space same as developers
and analysts
• Team leaders need to trust developers and analyst to deliver
• Provide support for attending conferences, training, or anew
software
package for developers/analysts to work with
Staffing the Project – Motivation
• Strategies a project manager can use to avoid conflicts:
• Clearly define plans for the project
• Make sure the team understands the importance of the project
to the
organization
• Develop detailed operating procedures and communicate them
to team
members
• Develop a project charter
• Develop schedule commitments ahead of time
• Project other priorities and the impact they could have on he
project
Staffing the Project – Handling Conflicts

• Supports the development team during the development
process
• Environment deals with choosing the correct set of tools and
identify
the appropriate set of standards
• Infrastructure deals with developing, modifying, and reusing
predefined components, frameworks, libraries and design
patterns,
plus the appropriate level and type of documentation that will
be
created during the development process
• CASE tools: Automate parts or all of the development process,
for
example, ArgoUML. Some CASE tools can do Forward and
Reverse
engineering
Environment and Infrastructure Management
Types of Standards Examples
Documentation Standards The date and project name should
appear as a
header on all documentation
Coding Standards All modules of code should include a header
that
contains the developer’s name, last update date,
and a short description of the code

Procedural Standards All changes to a requirement must be
approved
by the project manager
Specification requirement
standard
Name of the software module to be created
Description of the software module
Due date
GUI design standards Labels appear in bold, size 18
The tab order moves from top to bottom order
Environment and Infrastructure Management - Standards
• With the aid of Use Case Points estimation worksheet (the
Excel file is
uploaded in Week 2 lessons), estimate the effort needed to
accomplish the following project:
A company is in need of a system that allows a number of IT
products vendors to
present their products for approval via a web portal, then the
Sure Products staff
web portal where staff can review and approve/disapprove the
product list sent by
vendors. The system should have a customer portal for
customers to view approved
products
Activity 1

• What is a Unified Process Model
• What is the project management workflow for Unified Process
Discussions
• Go through the slides of this class plus the notes you have
taken
• Go through the exercises, discussions, and examples
• Read the slides for next class (will be available one day prior
to next
class)
• Continue working on your project
• Continue working on your assignments
• Work on your presentation
Before next class
Class and Method Design
Dr. Ardeshir Badr
Objectives

• Become familiar with how to create classes, add attributes and
methods
• Become familiar with how to instantiate objects from classes
• Become familiar with how to send messages to an object
• Be able to identify the reuse of predefined classes and
libraries
• Class and method design is the most important part of the
design workflow
• During design, instructions and guidelines are created for
developers of the classes
telling them how to code classes
• Low level detailed design at this stage is critical in spite of
reusable class and libraries
available, because:
• Using CASE tools, a lot of code can be generated from
detailed design
• Even pre-exiting classes and components need to be
understood and organized
• It is common for the developers to write code and produce
classes from detailed design
• We should not jump into coding without careful class design
first

Classes and Method Design
Levels of abstraction in Object Oriented Systems
System
Package
Class/Object
Variable/
Attribute
Method
Library
Higher
Lower
Classes and Objects, Methods
and Messages
Patient
-name
-address
-birthdate
-phone
-insurance carrier

+make_appointment()
+calculate_last visit()
+change_status()
+provide_medical_history()
+create()
James Frank : Patient
Andy Jones : Patient
Class
Objects
A Class is the general template to define and create instances,
or objects
An Object is an instantiation of a class
Attributes describe information about an object, for example,
patient’s
name, birth date, address, and phone number
Attributes can also represent relationships between objects, for
example,
a department attribute in an employee object that refers to the
value of
a department object that captures in which department the
employee
object works
The behavior in each object specifies what the object can do,
for
example, an appointment object can schedule a new
appointment,
delete an appointment, and locate the next available time/date.

Behaviors are implemented as methods
Messages are information sent to objects to trigger methods,
which is
essentially calling of the function or procedure of one object by
another
object
Attributes
Methods
Encapsulation and Information Hiding
• Encapsulation is the combination of data and process into a
single
entity
• Information hiding suggests that only the needed information
to use
a software module be published to the user of that module. For
example, the internal mechanism of a function does not need to
appear to a user of that function as long as the function occurs
• The fact that we can use an object by calling its methods
makes
reusability possible
• The only information that an object needs to know about
another
object is the set of methods and what messages need to be sent
to
trigger them

Inheritance
Person
Doctor Patient
General Practitioner Specialist
Superclass for
Doctor and
Patient
Superclass for
General
Practitioner and
Specialist
Abstract
class
Abstract
class
Concrete
class
Concrete
class
Concrete
class
Classes are arranged in a hierarchy of

superclasses or general, and
subclasses or specific classes
Subclasses inherit the appropriate
attributes and methods from the
superclasses above them
Concrete classes are the ones that
have instances
Classes that produce no instance and
are used as templates for other more
specific classes are called abstract
classes
Inheritance
Doctor
-medical_school_specialty
+update_medical_specialty()
Patient
-insurance_carrier
+update_insurance_carrier()
Patient
-name
-address
-birthdate

-phone
-insurance_carrier
+update_birth_date()
+update_insurance_carrier()
Doctor
-name
-address
-birthdate
-phone
-medical_school_specialty
+update_birth_date()
+update_medical_specialty()
Person
-name
-address
-birthdate
-phone
+update_birth_date(}
Polymorphism and Dynamic Binding
aCircle
aTriangle
In Polymorphism the same message can be
interpreted by different classes of objects

differently. For example, if an artist sent the
message Draw_yourself to a Circle object and a
Triangle object, the results will be different even if
the message is the same
Dynamic Binding makes polymorphism possible.
Dynamic binding or late binding is a technique that
delays typing the object until run time
In Static binding the object type is determined at
compile time
anArtist
Polymorphism example in Python
class Bear(object):
def sound(self):
print ('Groarrr')
class Dog(object):
def sound(self):
print ('Woof woof!')
def makeSound(animalType):
animalType.sound()
bearObj = Bear()
dogObj = Dog()
makeSound(bearObj)
makeSound(dogObj)

class Circle(object):
def draw_yourself(self):
print ('Drawing Circle')
class Triangle(object):
def draw_yourself(self):
print ('Drawing a Triangle')
def draw_a_shape(shape):
shape.draw_yourself()
circle = Circle()
triangle = Triangle()
draw_a_shape(circle)
draw_a_shape(triangle)
11
Python
✓ For Windows users:
✓ go to: https://www.python.org/
✓ Click on Downloads and under Downloads for Windows
select Python 3.6.3
✓ Save python-3.6.3.exe
✓ Run python-3.6.3.exe (as administrator if possible)

✓ Once installed, go to Start and then select Python from the
list of applications
✓ Under Python, select Python command line
✓ For Mac users:
✓ go to: https://www.python.org/
✓ Click on Downloads and select Mac OS X
✓ Select Python 36.3
https://www.python.org/
https://www.python.org/
Visual Studio Community Version
• https://www.visualstudio.com/downloads/
• Visual Studio Community 2017
• Click on Free Download
• Save the file vs_community__1034607155.1487127638.exe
• Double click on vs_community__1034607155.1487127638.exe
• In Workloads window, Select .NET Desktop Development to
be installed and click
on Install
• After installation completed click on Launch

• Create a new project by File -> New Project
• Under Visual C# select Windows Classic Desktop, and select
Console App
• Give an appropriate name and select/create a suitable folder to
save your project
IDE
https://www.visualstudio.com/downloads/
C#
• https://docs.microsoft.com/en-us/dotnet/csharp/programming-
guide/
• The link above provides information to C# language features
Programming
language
https://docs.microsoft.com/en-us/dotnet/csharp/programming-
guide/
• A good design is one that balances trade-offs to minimize the
total cost of
the system over its entire life time
• Criteria to evaluate a good design:
• Coupling: How interdependent or interrelated classes, objects,
and methods are
• Cohesion: How single-minded a class, object, or method is

within a system
• Connascence: Generalizes the idea of cohesion and coupling
and combines them
with the argument for encapsulation
Design Criteria
• The higher the interdependency, the more likely changes in
part of a design can cause
changes to be needed in other parts of a design
• Coupling type:
• Interaction coupling: Coupling among methods and objects
through message passing.
Interaction coupling should be minimized.
• Demeter law: An object should send message only to one of
the following: Itself, an object that
is contained in an attribute of that object, an object that is
passed as a parameter to the
method, an object that is created by the method, or an object
that is stored in a global variable
• Inheritance coupling: How tightly coupled the classes are in
the inheritance hierarchy. A
high level of inheritance coupling, for example subclasses
calling super classes methods,
should be avoided as much as possible
• Ensure inheritance is only used to support
generalization/specialization semantics and the
principle of substitutability

Coupling
• A class or object should represent only one thing, and a
method should solve only a
single task
• Types of cohesion:
• Method cohesion: A method should focus on doing only one
thing. From good to bad,
theses are method cohesion type:
• Functional, Sequential, Communicational, Procedural,
Temporal, Logical, Coincidental
• Class cohesion: Is the level of cohesion among the attributes
and methods of a class. A class
should represent only one thing and attributes and methods
contained in that class should
be required for the class to represent the thing
• Ideal class cohesion: Should have multiple methods that are
visible, and each visible method
contains only a single function, all methods reference only
attributes or other methods defined
within the class, an no control coupling between the visible
methods
• From good to bad class cohesion types: Ideal, Mixed-Role,
Mixed-Domain, Mixed-Instance
• Generalization/specialization cohesion: How are the classes in
the inheritance hierarchy
related. A kind of relationship should exist in the class

hierarchy semantically
Cohesion
• A software quality metric to allow reasoning about the
complexity caused by dependency
relationship in Object Oriented Design
• Two class or methods are so intertwined that a change in one
would necessitate a change in
other
• We should minimize Connascence by eliminating unnecessary
Connascence:
• Minimize Connascence across class and method boundaries
• Maximize Connascence within any encapsulation boundary
• Type of Connascence:
• Name: A method refers to the name an attribute and if the
attribute name changes, the method has
to change
• Class: A class has an attribute A, and if the attribute type
changes the attribute declaration has to
change
• Convention: A class has an attribute in which a range of
values has a semantic meaning. If the range
changes then every method that uses that attribute has to be
modified
• Algorithm: Two different methods rely on an algorithm to
execute correctly and if the algorithm

changes the methods has to change
• Position: The order of code in a method or the order of
parameters to a method is important and if
is not correct it could affect the method
Connascence
Object Design Activities
Add
Specifications
Identify
Opportunities for
reuse
Restructure
the Design
Optimize the
Design
Map Problem
Domain Classes to
Implementation
Language
1. Add any missing
attributes, methods,
classes

2. Finalize the visibility
of each attribute and
method in classes
(language
dependent)
3. Decide on the
signature of
methods: name of
method, parameters
and type, type of
value method
returns
4. Add constraints, e.g.,
attributes of an
object can have
values in certain
range and error
handling
1. Use of design
patterns, e.g.,
forwarder-receiver
pattern
2. Frameworks which is
a set of implemented
classes that can be
used as basis for
implementing an
application
3. Libraries has a set of
implemented classes
that were designed

for reuse, e.g., data
management layer
library
4. Component is a set of
self-contained,
encapsulated piece of
software that can be
plugged into a system
1. Factor
2. Normalize: All
associations
relationships must
be converted into
attributes in the
classes
3. Ensure all
inheritance
relationships are
only
generalization/spe
cialization (a-kind-
of)
1. Review the access
paths between
objects and make
sure the paths are
not too long
2. Review each
attribute of each
class and move

attributes to the
calling class if only
read and update
methods are used
3. Review the
number of
messages sent by
each method. If
the number is high
the method
should be
optimized by using
index for example
1. Map the current design
to the capabilities of
the programming
languages, for example,
C++, JAVA, C#, Python
Sure Products class design
Draw a class diagram showing all classes, attributes, operations,
and
relationships for the following case:
• A company has a number of employees. The attributes of
Employee include
employeeID (primary key), name, address, and birth date. The
company has also
several projects. Attributes of Project include projectName and

startDate. Each
employee may be assigned to one or more projects, or may not
be assigned to a
project. A project must have at least one employee assigned,
and it may have any
number of employees assigned. An employee’s billing rate may
vary by project, and
the company wishes to record the applicable billing rate for
each employee when
assigned to a particular project. At the end of each month, the
company mails a
check to each employee who has worked on a project during
that month. The check
amount is based on the billing rate and the hours logged for
each project assigned to
the employee.
Activity
taken
to next
class)

Before next class
Moving from Analysis Modeling
to Design Modeling
Dr. Ardeshir Badr
Objectives
• Understand the verification and validation of the analysis
model
• Understand the transition from analysis to design
• Understand the use of factoring, partitions, and layers
Analysis Modeling Versus Design Modeling
• Purpose of analysis is to figure out what the business needs
are
• Purpose of design is to decide how to build the system
• Analysis Modeling focuses on functional requirements of an
evolving system
• Design Modeling incorporates the nonfunctional requirements,
that is, how the system will operate:
• Operational requirements
• Performance requirements

• Security requirements
• Cultural and political requirements
Validate
functional,
structural,
and
behavioral
models
Create a set
of factored
and
partitioned
analysis
model
Illustrate the class and
method design using
the class specification
contracts and method
specification
Design database,
map objects to
database objects;
design file structure
used for object
persistence
Design User interface
layer
Design physical
architecture layer
using deployment

diagrams, and
hardware and
software
specifications
System
specification
• The goal of the design is to create a blue print that can be used
to build the system
• Examine several design strategies and decide which one to
choose from
• Design strategies can be:
• Build the system from scratch
• Purchase a ready product and customize it
• Outsource the system development to other companies
• The viability of each strategy should be investigated by the
project team
• The strategy chosen influences the tasks during the design
• Regardless of the design strategy, the design of classes and
methods needs to be done
• Class diagrams, contract specification, method specification,
and database design are
used by development team to implement the system

Transition from Analysis to Design
• Before moving from analysis representation to design
representation, we need to make
sure that the models are consistent
• The process of ensuring consistency among models is called
balancing the models
• Balancing models:
• Balancing Functional and Structural Models
• Balancing Functional and Behavioral Models
• Balancing Structural and Behavioral Models
Verifying and Validating the Analysis Models
Functional
Models
Behavioral
Models
Structural
Models
• Ensure that use case diagrams, activity diagrams, and use case
descriptions
agree with class diagrams and object diagrams
• Balancing in 4 steps:

1. Every class on a class diagram must be associated with at
least one use case, and
every use case must be associated with at least one class
2. Every action on an activity diagram and every event in a use
case description
should relate to one or more operations in a class on a class
diagram, and vice
versa
3. Every object node on an activity diagram must be associated
with an instance of a
class on a class diagram
4. Every attribute and association relationship in a class on a
class diagram should be
related to the subject or object of an event in a use case
description
Balancing Functional and Structural Models
Functional
Models
Activity
Diagrams
Use Case
Diagrams
Use Case
Description

including
Contains
Flows Object
nodes
Actions
HasKinds
Object
flows
Control
flows
Contains
Relationships
Actors
EventsStakeholders
Contains
Use
Cases
Have
Scenarios
Structural
Models

Class
Diagram
Object
Diagram
including
Contains
Classes
Associations/
Relationships
Contains
Attributes Operations
Objects
Contains
InstanceOf
HasKinds
Association Generalization
HasKinds
Association
Class
AssociatedWith

AssociatedWith
AssociatedWith
AssociatedWith
Relationship among Functional and Structural Models
• The analysis models are evolved into design models by adding
system environment or solution
domain details to them
• From a Unified Process perspective we are moving from
analysis workflow into design workflow
and moving further into elaboration phase and particularly
construction phase
• An approach to evolve analysis models into design models is
the use of:
• Factoring
• Partition and Collaborations
• Layers
Evolving the Analysis Models into Design Models
After Balancing the Use Cases, Activity Diagrams, and
Class/Object Diagrams

• Factoring is the process of reviewing a set of classes and
factoring out
similarities into a new separate class
• The new class can have class can have superclass relationship
to existing
classes through generalization
• Example: Factoring out the similar methods and attributes
from the Doctor,
Nurse, Receptionist classes can result in Employee superclass
• Abstraction: Creating higher level ideas from a set of ideas,
for example,
Employee class is abstracted from Doctor, Nurse, and
Receptionist classes.
Abstraction can identify abstract classes or concrete classes
• Refinement process is the opposite of abstraction, for
example, we can
identify additional subclasses of the Employee class, namely
Secretary, or
Book Keeper
Factoring
• The purpose of identifying collaborations and partitions is to
determine which classes should
be grouped together in design
• A partition is the decomposition of a large system into its
component subsystems, for example,
an accounting system could be functionally decomposed into an
account payable, account

receivable, and a payroll system. Partitions depend on messages
sent among the objects, or in
other words depend on collaboration
• We can model collaboration between objects in terms of
client, server, and contract. A client is
an instance of a class that sends message to an instance of
another class for a method to be
executed. A server is the instance of a class that receives the
message, and a contract is the
specification that formalizes the interaction between the client
and the server objects. The
potential partitions can be built by looking at the number of
contracts between objects. The
more contracts there are between objects, the more likely that
objects belong to the same
partition
Partition and Collaboration
• A layer represents an element of the software architecture of
the evolving system. We use MVC
(Model View Controller) as a model
• Layers:
• Foundation: Contains foundation classes, for example,
fundamental types (integers, real numbers,
character strings) and container classes (lists, trees, graphs,
sets, stacks, queues) and utility classes (date,
money). The foundation classes are usually included in the IDE
(Integrated Development Environment)
• Problem Domain: The analysis workflow and what we have

been focusing up until now
• Data Management: Addresses the persistence of objects in the
system, for example, creates a RDBMS
to store objects data. The classes in this layer deal with how
objects can be stored and retrieved from a
data store
• Human Computer Interaction: Contain classes that deal with
human interactions with a system, for
example, buttons, drop down lists, text fields
• Physical Architecture: Addresses how the developed software
will execute on specific computers and
networks, and contains classes that deal with communications
between the software, the operating
system and the network. Choice of operating system, memory
requirements, physical data storage,
input/output technology, standardization, virtualization, grid
computing, distributed computing, and web
services are also addressed in this layer
Layer
• Custom Development: Building a system from the scratch by
development team which
gives much control over the software developed and builds
technical and functional
skills within the company, however, consumes a lot of human
resources and can become
a risky venture
• Packaged Software: Companies have needs that can be met by
packaged software, for

example, payroll or accounting. Buying these developed and
tested software makes
more sense than developing them from the scratch. Packaged
software can range from
small to huge ERPs (Enterprise Resource Planning)
• Outsourcing: Hiring an external vendor to create the system,
which requires two way
coordination, exchange of information, and trust. Cloud service
providers are often
outsourced by many companies. Before outsourcing, a company
must have gone
through analysis workflow properly and thoroughly, and choose
the right outsourcing
company with the right skills and a good track record
Design Strategies
Custom development Packaged software Outsourcing
Business need The business need is unique The business need is
common The business need is
not core to the
business
In house experience In house functional and technical
experience exists
In house functional experience
exists
In house functional or
technical experience
does not exist

Project skills There is a desire to build in
house skills
The skills are not strategic The decision to
outsource is a
strategic decision
Project management The project has a skilled PM and
a proven methodology
The project has a PM that can
coordinate the vendor’s efforts
The project has a
skilled PM at the level
of the organization
that matches the
scope of the
outsourcing deal
Time frame The time frame is flexible The time frame is short
The time frame is
short or flexible
Selecting a Design Strategy
• Request For Proposal (RFP): A document that contains the
system specifications and asks a formal proposal from one or
more potential vendors, developers, or service providers to
provide their solutions. Once the winning vendor is chosen, a
contract is signed by both parties
• Alternative Matrix: Is used to organize the pros and cons of

the design alternatives in a way that the best solution can be
chosen
Selecting an Acquisition Strategy
Evaluation Criteria Relative
Importance
(Weight)
Alternative
1:
Score
(1-5)
Weighted
Score
Alternative
2
Score
(1-5)
Weighted Score
Technical Issues:
• Criterion 1
• Criterion 2
Economic Issues:
• Criterion 3

• Criterion 4
Organizational Issues:
• Criterion 5
• Criterion 6
Total 100
Activity
• Research the internet to find a cloud service provider that can
offer
payroll SAAS. Describe the provider and list the advantages and
dis-
advantages of the service and service provider.
• Select a design strategy for the following project:
ABC consulting is a firm specialized in IT consulting. The
company has a
legacy recruiting system that is running on on-premise servers.
The
current recruiting system is not capable of scaling to response
to high
demands. ABC consulting is looking to renovating their
recruiting
system. Can you suggest a design strategy that fits the
requirements of
this company. Discuss the merits of your choice.

Before next class
taken
to next
class)

Structural ModelingDr. Ardeshir BadrObjectives• .docx

Recommended

Recommended

More Related Content

Similar to Structural ModelingDr. Ardeshir BadrObjectives• .docx

Similar to Structural ModelingDr. Ardeshir BadrObjectives• .docx (20)

More from susanschei

More from susanschei (20)

Recently uploaded

Recently uploaded (20)

Structural ModelingDr. Ardeshir BadrObjectives• .docx