Guilherme H. Travassos - cs.umd.edumvz/mswe607-f00/notes-5b1.pdf · Guilherme H. Travassos ght UMCP...

1

CMSC 735A Quantitative Approach to SoftwareManagement and Engineering

UFRJCOPPEBrazil

Guilherme H. Travassoshttp://www.cos.ufrj.br/~ght

UMCP - CSESEG

Models and Measures (Product)

UMCP - CSESEGUFRJ/COPPE

CAPES - Brazil

Outline

y INTRODUCTIONx Products Measurement

y Part I: OO MODELSx Object-Oriented Paradigmx Engineering Object-Oriented Softwarex Representing OO Software Products using UML

• High-Level Design• Low-Level Design

y Part II: OO MEASURESx Object-Oriented Software Measurement

• High level design• Low level design• Coding• Testing

2


CAPES - Brazil

y INTRODUCTIONx Products Measurement




CAPES - Brazil

Products Measurement

y Metrics for any engineered product are governed by the uniquecharacteristics of the product

y As for conventional software, OO metrics aim to:x better understand the quality of the productx assess the effectiveness of the processx improve the quality of work performed

What makes an OO product different from a conventional one?How do we measure the quality of an OO system?What characteristics of the design model can be assessed to determine

whether the system will be easy to implement, amenable to test,simple to modify, and most important, acceptable to end users?

3


CAPES - Brazil

Engineering Conventional Products

y the solution is function or data centeredy it uses algorithms, procedures (with different notations

across the life-cycle) and data organization to describe theproblem and organize information

y basically, modules arrange the software architecturey information structuring technology (relational model, for instance)

determines how the information will be stored and evaluated



CAPES - Brazil


Engineering Conventional Systems:y functional decomposition (structured development) and some possible

metricsa

b c d

e f

1

23

Program ado while Xcall b;call c;call dend while;

Subroutine ccall e;if y then call fend;

Specification Design ImplementationFunction Pointspages of documentationestimated lines of codecalendar time...

CohesionCouplingComplexityNumber of Modules...

Cyclomatic complexityHalstead’s theorylines of codeData bindingsSpan...

Testing

CoverageReliability...

4


CAPES - Brazil


Object Oriented Paradigm:

y means to organize the software as a collection of discreteobjects that incorporate both data structure and behavior

y characteristics:

identityabstractionclassificationencapsulation

inheritancepolymorphismpersistence


CAPES - Brazil

y Part I: OO MODELSx Object-Oriented Paradigmx Engineering Object-Oriented Softwarex Representing OO Software Products using UML

• High-Level Design• Low-Level Design



5


CAPES - Brazil

Object-Oriented Paradigm

Identitydata is organized intodiscrete, distinguishableentities called objects

an object has states andbehaviors. A reference(handle) distinguishesdifferent objects


CAPES - Brazil


Abstraction

How many viewpoints(perspectives)can be used while building asystem?

Abstractions form a hierarchy!

6


CAPES - Brazil


Classification

an important OOdevelopment activity

depends on the abstractionlevel and the viewpoint(perspective)used by the developer


CAPES - Brazil


Classification

Objects with the samefeatures (attributes andbehaviors) are grouped into aclass

Each class defines apossibly infinite setof objects

7


CAPES - Brazil


Classification

Bicycle objects

Bicycle classAttributes

frame sizewheel sizegearsmaterial

Operationsshiftmoverepair

abstract

into

Polygon objects

abstract

into

Polygon classAttributes

verticesborder colorfill color

Operationsdrawerasemove


CAPES - Brazil


Classification Each object is said to be an instance of a class

Each object knows its class

Each instance keeps its ownattributes value (state) butshares attribute names andbehaviors (operations) withother instances of the class

8


CAPES - Brazil


Encapsulation

a class encapsulates attributes(names,types) and behaviors,hiding the object implementationdetails

Bicycle

frame sizewheel sizegearsmaterial

shift()move()repair()

102iron

66

plastic

8

paper

21

0

6 0

Polygon

verticesborder colorfill color

draw()erase()move()

3yellow

red

4green

blue

4white

black

id


CAPES - Brazil


Inheritance

the sharing of attributes andbehaviors among classes basedupon a hierarchical relationship

A class can be defined broadly andthen refined (specialized) intosuccessively finer subclasses

Each subclass incorporates or inherits all theproperties of its superclass(es) and its ownspecialized properties

9


CAPES - Brazil


Structure identification:

class hierarchy using single inheritance

Person

nameage

DoctorOffice

attend_patient()

Nursehospital

Surgeonspecialty

Family Doctorhome address

Surgeonnameageofficespecialty

attend_patient()

Family Doctornameageofficehome address

attend_patient()

Nursenameagehospital

Doctor

nameageoffice

attend_patient()

abstract class


CAPES - Brazil


Polymorphism the same behavior may behavedifferently on different classes

a behavior (operation) is an actionor transformation that an objectperforms or is subject to.Normally, these actions are takenas response for some stimulus(message)

10


CAPES - Brazil


Polymorphisma specific implementation of anoperation for a certain class iscalled a method

an operator may have morethan one methodimplementing it

an OOPL automatically elects the correct method to implement anoperation based on the name of the operation, carried data(parameters) and object’s class being implemented (methodsignature)

therefore, new classes can be added without changing existing codeDoctor

nameageoffice

attend_patient()

Surgeonnameageofficespecialty

attend_patient()

Family Doctornameageofficehome address

attend_patient()


CAPES - Brazil


Persistence

the object state and its behaviorswill be saved across the time orspace

an object existencetranscends time and/or space

11


CAPES - Brazil

Engineering Object-Oriented Software

OO Software Process Features:y works with the encapsulation of data and behavior into independent

units (objects)

y uses the same set of semantic constructs to represent the system fromthe requirements to the application

y supports different software life-cyclesy stimulates reuse

In general, it deals with (but not using a totally sequential approach):

y requirements description (textual description and scenarios)

y high-Level designy low-Level designy codingy testing


CAPES - Brazil

Engineering Object-Oriented SoftwareHigh Level Design:

y Classes/Objects identificationx real world (problem domain) objects definitionx attributes and behaviors detailing

y Classes/Objects interaction identificationx association and aggregation relationshipsx probably some inheritance relationships

Low-Level Designy inserting computational features into the models (user interface, tasks,

persistence,…) and some class libraries details (uses a bottom-upapproach)

y good time to deal with non-functional requirements (performance,security, etc.)

y classes contract preparationy starting code

12


CAPES - Brazil


Coding

y translates OO models to some OO programming languagey refines hierarchical structuresy in some situations, makes some generalization for future use

(components)

Testing

y unit testingy integration testingy system testingy acceptance testing

Classhierarchy

Class

Cluster

Subsystem

System

Unittesting

Systemtesting

Acceptancetesting

Integrationtesting

Abst

ract

ion

leve

l

Figure 1: O.O. Testing level


CAPES - Brazil


Representations

y Static views:x objectsx attributesx behaviorx relationships: generalization, aggregation and inheritance

y Dynamic views :x communicationx control/temporizationx states

y Restrictions:x in the structure (attribute values, relationship cardinality )x in the dynamic behavior

13


CAPES - Brazil

Representing OO Software Product usingUnified Modeling Language - UML

UML can be used to

x specify,x visualize, andx document

the design artifacts of a

system under development

UML is just a notationalapproach and does notpropose/define how toorganize tasks design.Therefore, it can betailored to fit differentdevelopment situationsand software lifecycles.

Dynamic ViewDynamic View y use casesy activitiesy interaction

x sequences

x collaborations

y state machines

Static ViewStatic Viewy classes

x Relationships• Association• Generalization• Dependency• Realization

x Extensibility• Constraints• Tagged values• Stereotypes

y packagesy deployment

UML DiagramsUML Diagrams

OO Design ArtifactsOO Design Artifacts

Actually, it has beenadopted by the OMG(Object Managementgroup) as the OOnotational standard

Restrictions and FormalizationRestrictions and Formalizationy OCL - Object Constraint

Language


CAPES - Brazil

Representing OO Software Product usingUnified Modeling Language - UML

High and Low Level Design Coding and Testing

class partsinherit from Stock_items;attributes …services …..relationships ...

RequirementsDescription and Use Cases

…3 – A gas station ownercan use the system tocontrol inventory. Thesystem will either warnof low inventory orautomatically order newparts and gas.

...

Fixed_Rate Loan

risk()principal_remaining()

Variable_Rate Loanprincipal_remaining : number

risk()principal_remaing()

Lendername : tex ti d : t e x tcontact : textphone_number : number

Borrower

name : textid : numberrisk : numberstatus : text

risk()set_status_good()set_status_late()set_status_default()borrower_status()set_status()

Bundleact ive t ime period : dateprof i t : numberestimated risk : numbertotal : numberloan analyst : id_numberdiscount_rate : number

investor_name : textdate_sold : date

risk()calculate_profit()cos t ( )

Loan Arranger

rec_monthly_report()inv_request()generate reports()identify_report_format()verify_report()

look_for_a_lender()look_for_a_loan()identify_loan_by_criteria()manually_select_loans()optimize_bundle()calculate_new_bundle()identify_asked_report()aggregate_bundles()aggregate_loans()aggregate_borrowers()aggregate_lenders()format_report()show_report()

Loanamount : numberinterest rate : number

settlement data : datet e r m : d a t estatus : textoriginal_value : numberprincipal_original : number

risk()set_status_default()set_status_late()set_status_good()discount_rate()

borrowers()principal_remaining()

1

1..*

1

1..*

1..*1..*

1..*1..*

1..*

0 . .1

1..*

0 . .1

Good

Late

monthly report informing payment on time

[ payment time <= due time ]receive a monthly report

D e f a u l t

monthly report informing late payment[ payment time > due time + 10 ]

monthly report informing late payment

[ due time < payment time < due time + 10 ]

monthly report informing late payment[ payment t ime > due t ime + 10 ]

monthly report informing payment on time[ payment time <= due time ]

Loan State

Diagram

Fanny May : Loan Arranger

Bor rower : Borrower

A Lender :

Spec i f ied Lender

Loan : Loan

verify_report()

new_loan(lender, borrowers)

new_

look_for_a_lender(lender)

look_for_a_loan(loan)

look_for_a_

update_loan(lender, borrower)

update_

lender :

new_lender(name,contact, phone_number)

update(lender)

monthly_report(lender, loans, borrowers)

identify_report_format()

Receive Monthly Report

Loan Arranger Classes Description

Class name: Fixed_Rate Loan Category: Logical View Documentation: A fixed rate loan has the same interest rate over the entire term of the mortgage

External Documents: Export Control: Public Cardinality: n Hierarchy: Superclasses: L o a n Public Interface: Operations: risk principal_remaining

State machine: No Concurrency: Sequent ial Persistence: Persistent

Operation name: risk Public member of: Fixed_Rate Loan Return Class: f l o a t Documentation: take the average of the risks' sum of all borrowers related to this loan if the average risk is less than 1 round up to 1 else if the average risk is less than 100 round up to the nearest integer otherwise round down to 100 Concurrency: Sequential

14


CAPES - Brazil

High-Level Design

UML Use Cases

y capture some participant-visible functiony can be used to represent system’s utilization contextsy show some of the system requirements using high abstraction

level

Diagram elements:x actor: is a role that a participating plays to the systemx use-case: shows the visible system functionalityx extensions: extends a use-casex uses: reuse of use-cases


CAPES - Brazil

High-Level Design

The Gas Station Use-Cases

Owner

Customer

CC System

Gas ordering system

Controlling inventory

Parts ordering system

maintenance services

Parking servicesGas services

accounting services

billing

Printer system

15


CAPES - Brazil

High-Level Design

UML Class diagramy captures problem vocabularyy relates everything togethery models information in a systemy anchors behavior to classesy generates class structure declarations

UML Relationshipsy association

x aggregation: is the part-of relationshipx composition: the whole

salesman 1..*1

ordered item

1

1..*Customer

ordersends

includeshas

name : stringaddress : stringbirthday : date

Customer

pay_by_cash()

1Class name

Attribute:Type = initial Value

operation(arg list):return type


CAPES - Brazil

Partpart_code

pricediscount rate

min_quantity = 2current_quantity

gas ordering system

inventory

order_gas()order_part()

1..*

1

parts ordering system

car maintenanceprice = 150.00

price()

0..*

periodic messages

messagetext

CustomernameaddressSSNbirthday

account_number

warning letters

billissue datepayment date

price()taxes()

gasmin_quantity = 100current_quantity

1

1

refuelgallonsprice = 1.09

price()1

0..*

parking spotplace

is_available()

parkingprice = 5.00

1

0..1

servicesdiscount rate

price()

Purchasedatetax = 0.05

price()taxes()

1..*1

1

0..*

1..*

0..*

gas station

dormant_accounts()

CC system

0..*

1

0..1

1

0..*

11

11..*

1

0..*

1..*1

1..*

0..*

An example of a class diagram

16


CAPES - Brazil

High-Level Design

A Class DescriptionClass name: refuel Category: Service External Documents: Export Control: Public Cardinality: n Hierarchy: Superclasses: services Associations: <no rolename> : gas in association <unnamed>

Public Interface: Operations: price Private Interface: Attributes: gallons price = 1.09 Implementation: Attributes: gallons price = 1.09 State machine: No Concurrency: Sequential Persistence: Transient

Operation name: price Public member of:refuel Documentation: // Calculates the final price of the fuel Preconditions: gallons > 0 Object diagram: (Unspecified) Semantics: final_price = gallons * price Object diagram: (Unspecified) Concurrency: Sequential


CAPES - Brazil

High-Level Design

UML Package diagramsy used to break down a large system into smaller and meaningful sets of

classes (clusters)y shows the dependency among classes of different packages. A

dependency exists between two elements if changes to the definition of oneelement may cause changes to the other (coupling)

x Possible dependencies between two classes:• one class sends a message to another one• one class has another one as part of its data

• one class mentions another one to be a parameter to an operation

y packaging is a vital technique for large projects:x allows keeping system’s dependencies to a minimum reducing couplingx is particularly useful for testing

17


CAPES - Brazil

High-Level Design

UML Package diagram

External Systems

Products

Customers

Service

Packaging GasStation classes

car maintenanceprice = 150.00

price()

refuelgallonsprice = 1.09

price()

servicesdiscount rate

price()

parking

price = 5.00

parking spotplace

is_available()

0..11

0..11

package

dependency

package contents


CAPES - Brazil

High-Level Design

UML Interaction diagramy used to describe how a functionality can be obtained from the objectsy typically, one interaction diagram represents just one use-casey good to represent sequential functions, without much conditional or

looping controly two types of interaction diagrams:

x sequence diagramsx collaboration diagrams

18


CAPES - Brazil

High-Level DesignSequence diagrams

y an object is shown as a box at the top of a dashed vertical line (object’slifeline)

y an arrow between two objects lifelines is called a message (labeled atleast with the message name):

x self-delegation: a message that an object sends to itselfx condition: indicates when a message is sentx iteration marker: shows that a message is sent many times to multiple

receiver objects

y puts emphasis on the sequence of actions instead of the relationshipsbetween objects


CAPES - Brazil

High-Level DesignSequence diagram

Customer :Customer

Gas Station Owner :Gas Station Owner

Credit Card System :Credit_Card System

Purchase :Purchase

Customer Bill :Bill

Parking Spot :Parking_Spot

parking_spot_request( account_number)next_available( )

where_to_park( available parking_spot)

lease_parking_spot(parking_spot, payment time, payment type)

authorize_payment(customer, amount, date)

[ Payment type = Credit Card and payment time = now]

new_purchase(customer, parking_spot, date)

add_to_bill(customer, amount, date)

[ payment time = monthly]new_payment_type_request()

[ response time => 30 secs orcredit card not authorized andpayment time = now]

[response time < 30 secs]

services

19


CAPES - Brazil

High-Level Design

Collaboration diagramsy objects are shown as iconsy arrows from the sender to receiver show the

messages senty a number indicates the message ordery emphasizes which objects are statically

connected

2: operation name(parameters list)

1: operation name(or an event)

:class name :class name

Object:class name

attributesattribute = value


CAPES - Brazil

High-Level Design

GasStation

Parking Spot

Purchase

Parking

1: Parking() 3: parking_at(place)

2: next_available()

4: new_purchase(customer,parking,date, place)

5: new_parking(customer,place)

Customercollaborationdiagram

Gas StationParking use case

20


CAPES - Brazil

High-Level Design

UML State diagramsy show possible object states, events that induce the transition from one

state to another and possible actions associated to these eventsy represent the dynamic model view of a simple object, object’s hierarchy

or the whole systemy Normally, are only prepared for classes whose instances are very

dynamic

object state ≡ attributes valueevents ≡ messages


CAPES - Brazil

High-Level Design

UML State diagrams

y Notationx state:

• means cumulative results of theobject behavior/systemfunctionality

x transition (event):• some occurrence which can

induce an object/system statechange

authorizing

authorized

start

endstate

transition

state actions:actions can be associated to states

conditional transition:some transition will be occur if acondition can be satisfied

nesting states:states can be partitioned

Authorizing

Authorized

Purchased

Rejected

[payment not OK][payment ok]

[time <= 7]

21


CAPES - Brazil

High-Level Design

Gas Station states diagrams

available

not available

Customer_request

Customer release

parking spot

place : Strings

is_available()next_available()inventory

order_gas()order_part()

normal stockLow gas

Low parts

ordering parts

ordering gas

parts low in stock

gas low in stock

delivery gas delivery parts


CAPES - Brazil

High-Level DesignUML Activities diagram

y can be used to model procedures activity flowy an activity is similar to a statey an event is similar to an transitiony decisions can be represented if an activity has more than one eventy normally, are associated to states diagrams of several classes

activity A activity B

startInitial activity activity X end

transition

activity B

activity C activity D

decision output A

output B The bar shows that one activity canbroadcast data to other activities(parallels or not determined activities)

22


CAPES - Brazil

Low-Level Design

y Advantages while using the same notation

x developers don’t need to learn/use different constructs andrepresentation

x analysis/design transition is an entwining and soft processx it improves reuse, extensibility and readabilityx the results from the High-level design compose the initial problem

domain design that should be modified and extended to satisfy allnon-functional requirements


CAPES - Brazil

Low-Level Designx Problem domain design

• model modification:– early projects and coded classes reuse– adjusting supported inheritance level– performance and I/O issues– data management support– low level components– high level design extensions review

• Creating/Destroying Objects– defines how each concrete class may create its objects (instantiation)– describes how objects might be destroyed– it’s important to observe the restrictions applied to the class structure

to maintain model consistency• Inserting computational features: user interface, task and data

management• Decisions regarding deployment and physical software architecture

23


CAPES - Brazil

Low-Level Design

y For instance,User interface design Bill

Customer name:

Issue Date:

PurchasesDate Type Amount

Ok

Total:

Windowsizewidthcustomer_nameissue_datetotalpurchases

show_bill()

Ok_buttonTextBox

billissue date : DateTimepayment date : DateTime

price()taxes()customer()list_purchases()

1..*

1

Purchasedate : DateTimetax : float = 0.05

price()taxes()


CAPES - Brazil

Low-Level Design

UML Deployment diagramy show physical relationships among system’s software and hardware

componentsy useful to show components’ system distributiony basic notation:

x a diagram node means some computing unitx a node connection shows some communication possibility

x a component means a module (code)x components’ dependencies are the same as the packages’ dependencies

processor device

processor

connection

Package specification

Main program

task

24


CAPES - Brazil

Low-Level Design

Gas StationComponents

Order Parts

Products

GasStation

Customers

Services

Interface with external systems

Gas Station Processor

Cardreader

modem

CC System

Gas Ordering System

Parts ordering System

Gas StationDeployment Diagrams


CAPES - Brazil

Low-Level Designy Moving to code

x A bare classification of OO PL’s:• Pure:

– uses just OO constructs in its definition– enforces OO as the only approach to code

– uses dynamic binding all the time– good for prototyping

– normally, has tools to support OO coding, debugging andtesting

– Some examples.: SMALLTALK , EIFFEL, and JAVA

• Hybrid:– uses OO and non-OO constructs in its definition

– doesn’t enforce OO as the only approach to code– eventually, uses virtual functions to implement dynamic

binding

– tools supporting coding, debugging and testing do notadopt OO

– Some examples: C++, OO-COBOL, and OBJECT-PASCAL

25


CAPES - Brazil

Low-Level Design

Movingto code

PL Smalltalk Eiffel Java C++ Object-Pascal

FeaturesBinding dynamic dynamic dynamic static

dynamicstatic

dynamicOverlay allows allows allows partially partiallyGarbageCollection

automatic usercontrol

automatic none none

Inheritance simple multiple simple multiple simpleLibraries yes yes yes no noProductivity high high high medium/low mediumEnvironment nice nice nice good goodTools OO OO OO traditional tradition

alLearning slow medium medium medium fastHardwaredependency

low high high high high

UserInterface

Selfwindows

WindowsXWindows

WindowsXWindows

--- ---

Enforces OO yes yes yes no no

Choosinga PL


CAPES - Brazil

Low-Level Designclass parking : public Services{ public: // Constructors (generated) parking(); parking(const parking &right); //Destructor (generated) ~parking(); //Get and Set Operations for Associations (generated) const parking_spot * get_the_parking_spot () const; void set_the_parking_spot (parking_spot * value); protected: // Additional Protected Declarations private: //Get and Set Operations for Class Attributes (generated) const float get_price () const; void set_price (float value); // Additional Private Declarations private: // implementation // Data Members for Class Attributes float price; // Data Members for Associations parking_spot *the_parking_spot;};// Class parking

servicesdiscount rate : float = 0.0

price()

parkingprice : float = 5.00

10..1

parking spotplace : Strings

is_available()next_available()

Moving to code

Guilherme H. Travassos - cs.umd.edumvz/mswe607-f00/notes-5b1.pdf · Guilherme H. Travassos ght UMCP...

Documents

Transcript of Guilherme H. Travassos - cs.umd.edumvz/mswe607-f00/notes-5b1.pdf · Guilherme H. Travassos ght UMCP...