analysis and design - cinvestavertello/swe/sesion07.pdf · 2014-07-17 · analysis classes external...

Analysis and DesignAnalysis and Design

Eduardo Rodriguez‐Tello, PhD 1© Cinvestav‐Tamaulipas 2009 ‐ 2012

ContentContentAnalysis modeling concepts and approachesAnalysis modeling concepts and approaches

Data modeling

Object oriented conceptsObject oriented concepts

Scenario based modeling

Class based modeling

The design process

Design concepts

The design modelThe design model

Software architecture

A hit t l t lArchitectural styles

Software Engineering 2Eduardo Rodriguez‐Tello, PhD © Cinvestav‐Tamaulipas 2009 ‐ 2012

Analysis model, a bridgeAnalysis model, a bridge

system description

l ianalysis model

design model


Analysis modelAnalysis modelThe model should focus on requirements that are visible withinqthe problem or business domain. The level of abstractionshould be relatively highEach element of the analysis model should add to an overallunderstanding of software requirements and provide insightinto the information domain function and behavior of theinto the information domain, function and behavior of thesystemDelay consideration of infrastructure and other non functionalDelay consideration of infrastructure and other non‐functionalmodels until designBe certain that the analysis model provides value to allBe certain that the analysis model provides value to allstakeholdersKeep the model as simple as it can beKeep the model as simple as it can be


Data modelingData modelingExamines data objects independently of processingExamines data objects independently of processing

Focuses attention on the data domain

Creates a model at the customer’s level of abstractionCreates a model at the customer s level of abstraction

Indicates how data objects relate to one another

Data objects and attributesA data object contains a set of attributes that act as an aspect,

lit h t i ti d i t f th bj tquality, characteristic, or descriptor of the object

object: automobileobject: automobileattributes:

makemodelbody typebody typepriceoptions code


The ERD: An exampleThe ERD: An example

(1 1) (1 m)placesCustomer

requestfor service(1,1) (1,m) for service

(1 n)

(1,1)

workstandard generates (1,n) workorder

(1 1) (1 1)

standardtask table

(1,1)worktasks

consistsof

(1,1)(1,w)

(1,1)selected

from (1,w)

( , )

materials lists(1,i)


Object‐oriented conceptsObject oriented concepts

Must be understood to apply class‐based elements ofMust be understood to apply class based elements ofthe analysis model

Key concepts:Classes and objects

Attributes and operations

Encapsulation and instantiationEncapsulation and instantiation

Inheritance


ClassesClasses

Object‐oriented thinking begins with the definition ofObject oriented thinking begins with the definition ofa class, often defined as:

T l tTemplate

generalized description

“blueprint” ... describing a collection of similar items

A metaclass (also called a superclass) establishes aA metaclass (also called a superclass) establishes ahierarchy of classes

O l f it i d fi d ifi i t fOnce a class of items is defined, a specific instance ofthe class can be identified


Building a classBuilding a class

class name

attributes:attributes:

operations

operations:

attributes:


Encapsulation/HidingEncapsulation/Hiding

The object encapsulates both data and the logicalThe object encapsulates both data and the logicalprocedures required to manipulate the data

method # 1

method # 2

data

th dmethod

# 3method # 6

# 3

method # 4

method # 5


Class hierarchyClass hierarchyPieceOfFurniture (superclass)

ChairTable Desk ”Chable"

subclasses of the

instances of Chair


instances of Chair

MethodsMethodsAn executable procedure that is encapsulated in ap pclass and is designed to operate on one or more dataattributes that are defined as part of the class

A method is invoked via message passing


Scenario‐based modelingScenario based modeling

Use‐case diagrams: A scenario that describes a “threadUse case diagrams: A scenario that describes a threadof usage” for a system

UUse‐case

Actor

Statechart diagrams: Supplements the use‐case byproviding a diagrammatic representation of proceduralproviding a diagrammatic representation of proceduralflow

A ti it di All th d l t t thActivity diagrams: Allows the modeler to represent theflow of activities described by the use‐case and at thesame time indicate which actor or analysis class hasresponsibility for the action


p y

Class‐based modelingClass based modeling

Identify analysis classes by examining the problemIdentify analysis classes by examining the problemstatement

Use a “grammatical parse” to isolate potential classesg p p

d f h b f h lIdentify the attributes of each class

Identify operations that manipulate the attributes


Analysis classesAnalysis classesExternal entities (e.g., other systems, devices, people) that produce orconsume information to be used by a computer‐based systemThings (e.g, reports, displays, letters, signals) that are part of theinformation domain for the probleminformation domain for the problemOccurrences or events (e.g., a property transfer or the completion of a seriesof robot movements) that occur within the context of system operationRoles (e.g., manager, engineer, salesperson) played by people who interactwith the systemOrganizational units (e g division group team) that are relevant to anOrganizational units (e.g., division, group, team) that are relevant to anapplicationPlaces (e.g., manufacturing floor or loading dock) that establish the contextof the problem and the overall function of the systemStructures (e.g., sensors, four‐wheeled vehicles, or computers) that define aclass of objects or related classes of objectsclass of objects or related classes of objects


Selecting classes, criteriaSelecting classes, criteria

Retained informationNeeded servicesMultiple attributesMultiple attributesCommon attributesCommon operationsEssential requirementsEssential requirements


CRC modelingCRC modeling

Analysis classes have “responsibilities”Analysis classes have responsibilitiesResponsibilities are the attributes and operationsencapsulated by the classencapsulated by the class

Analysis classes collaborate with one anotherCollaborators are those classes that are required to providea class with the information needed to complete aresponsibility

In general, a collaboration implies either a request forg p qinformation or a request for some action


CRC modelingCRC modeling

Class:Description:

Class:Description:

Class:D i ti

Class: FloorPlanResponsibility: Collaborator:

Responsibility: Collaborator:Description:

Responsibility: Collaborator:Description:

Responsibility: Collaborator:defines floor plan name/type

manages floor plan positioning

scales floor plan for displayl fl l f di l

incorporates walls, doors and windows

shows position of video cameras

scales floor plan for display

Wall

Camera


Class typesClass typesEntity classes, also called model or business classes, are extracted directlyfrom the statement of the problem (e.g., FloorPlan and Sensor)

Boundary classes are used to create the interface (e.g., interactive screen orprinted reports) that the user sees and interacts with as the software is used

Controller classes manage a “unit of work” from start to finish. That is,controller classes can be designed to managecontroller classes can be designed to manage

the creation or update of entity objectsthe instantiation of boundary objects as they obtain information from entitybobjects

complex communication between sets of objectsvalidation of data communicated between objects or between the user and thevalidation of data communicated between objects or between the user and theapplication


ResponsibilitiesResponsibilitiesSystem intelligence should be distributed acrossSystem intelligence should be distributed acrossclasses to best address the needs of the problemEach responsibility should be stated as generally asEach responsibility should be stated as generally aspossibleI f ti d th b h i l t d t it h ldInformation and the behavior related to it shouldreside within the same classInformation about one thing should be localized with asingle class, not distributed across multiple classesResponsibilities should be shared among relatedclasses, when appropriate, pp p


CollaborationsCollaborationsClasses fulfill their responsibilities in one of two ways:Classes fulfill their responsibilities in one of two ways:

A class can use its own operations to manipulate its own attributes,thereby fulfilling a particular responsibility, or

a class can collaborate with other classes

Collaborations identify relationships between classesy p

Collaborations are identified by determining whether a classcan fulfill each responsibility itselfca u eac espo s b y se

Three different generic relationships between classes:The is‐part‐of relationshipThe is‐part‐of relationship

The has‐knowledge‐of relationship

The depends‐upon relationshipThe depends upon relationship


Associations and dependenciesAssociations and dependencies

Two analysis classes are often related to one anotherTwo analysis classes are often related to one anotherin some fashion

I UML th l ti hi ll d i tiIn UML these relationships are called associations

Associations can be refined by indicating multiplicity (the)term cardinality is used in data modeling)

In many instances, a client‐server relationship existsy pbetween two analysis classes.

In such cases a client‐class depends on the server‐class inIn such cases, a client class depends on the server class insome way and a dependency relationship is established


Multiplicity and dependenciesMultiplicity and dependencies

Wall

1 1 1

is used to buildis used to build

is used to build1 *

1 1 1

0 * 0 *

CameraDisplayWindow

{password}

<<access>>

WallSegment Window Door

is used to build1.. 0.. 0.. {password}


Analysis packagesAnalysis packagesVarious elements of the analysis model (e.g., use‐Various elements of the analysis model (e.g., usecases, analysis classes) are categorized in a mannerthat packages them as a groupingthat packages them as a groupingThe plus sign preceding the analysis class name ineach package indicates that the classes have publiceach package indicates that the classes have publicvisibility and are therefore accessible from otherpackagespackagesOther symbols can precede an element within apackage A minus sign indicates that an element ispackage. A minus sign indicates that an element ishidden from all other packages and a # symbolindicates that an element is accessible only toindicates that an element is accessible only topackages contained within a given package


Analysis packagesAnalysis packagespackage name

Environment

+Tree+Landscape+Road+Road+Wall+Bridge+Building+VisualEffect+Scene

RulesOfTheGame

+R l OfM t+Scene +RulesOfMovement+ConstraintsOnAction

Characters

+Player+Protagonist+Antagonist+SupportingRole


Analysis model – design modely g

use-cases - text use-case diagrams activity diagrams

data flow diagrams control-flow diagrams processing narratives

f low- or ient ed element s

scenar io- basedelement s

Component -Level Design

Analysis Model

y gswim lane diagrams

processing narratives

Int erface Design

behavioralelement s

class- basedelement s

class diagrams analysis packages CRC models collaboration diagrams

state diagrams sequence diagrams

Dat a/ Class Design

Archit ect ural Design

g

Design Model


Design and qualityDesign and quality

Design must implement all of the explicitDesign must implement all of the explicitrequirements contained in the analysis model, and itmust accommodate all of the implicit requirementsmust accommodate all of the implicit requirementsdesired by the customerDesign must be a readable, understandable guide forthose who generate code and for those who test andsubsequently support the software

Design should provide a complete picture of theDesign should provide a complete picture of thesoftware, addressing the data, functional, andb h i l d i f i l t tibehavioral domains from an implementationperspective


Quality guidelinesQuality guidelinesA design should exhibit an architecture that:g

Has been created using recognizable architectural styles or patternsIs composed of components that exhibit good design characteristicsCan be implemented in an evolutionary fashion

For smaller systems, design can sometimes be developedlinearly

A design should be modular; that is, the software should bel i ll titi d i t l t b tlogically partitioned into elements or subsystemsA design should contain distinct representations of data,architecture interfaces and componentsarchitecture, interfaces, and componentsA design should lead to data structures that are appropriate forthe classes to be implemented and are drawn from recognizablethe classes to be implemented and are drawn from recognizabledata patterns


Quality guidelinesQuality guidelinesA design should lead to components that exhibit independentg p pfunctional characteristicsA design should lead to interfaces that reduce the complexity ofconnections between components and with the externalenvironmentA design should be derived using a repeatable method that isdriven by information obtained during software requirementsanalysisanalysisA design should be represented using a notation that effectivelycommunicates its meaningcommunicates its meaning


Design principlesDesign principlesThe design should be traceable to the analysis modelg yThe design should not reinvent the wheelThe design should “minimize the intellectual distance” betweenThe design should minimize the intellectual distance betweenthe software and the problem as it exists in the real worldThe design should exhibit uniformity and integrationg y gThe design should be structured to accommodate changeDesign is not coding, coding is not designDesign is not coding, coding is not designThe design should be assessed for quality as it is being created,not after the factThe design should be reviewed to minimize conceptual(semantic) errors( )

From [DAV95]


[ ]

Design fundamental conceptsDesign fundamental concepts

Abstraction: data, procedure, controlAbstraction: data, procedure, control

Architecture: the overall structure of the software

Patterns: “conveys the essence” of a proven design solutionPatterns: conveys the essence of a proven design solution

Modularity: compartmentalization of data and function

Hiding: controlled interfaces

Functional independence: single‐minded function and lowcoupling

Refinement: elaboration of detail for all abstractionsf

Refactoring: a reorganization technique that simplifies thedesigndes g


The design modelghigh

class diagramsanalysis packagesCRCmodels

use-cases - textuse-case diagrams

class diagramsanalysis packages

Analysis model

Requirements:const raints

collaborat ion diagramsg

act ivity diagramsswim lane diagramscollaborat ion diagrams data f low diagrams

control-f low diagramsprocessing narrat ives

data f low diagramscontrol-f low diagramsprocessing narrat ives state diagrams

sequence diagrams

analysis packagesCRC modelscollaborat ion diagrams

interoperabilit ytargets and

conf igurat ion

state diagramssequence diagrams

design class realizat ionssubsystemscollaborat ion diagrams component diagramstechnical interfacecollaborat ion diagrams component diagrams

design classesact ivity diagramssequence diagrams

f i t t

design class realizat ionssubsystemscollaborat ion diagramscomponent diagramsdesign classesact ivity diagrams

Design model

technical interfacedesign

Navigat ion designGUIdesign

lowdesign class realizat ionssubsystemscollaborat ion diagrams

ref inements to:

deployment diagrams

ref inements to:component diagramsdesign classesact ivity diagramssequence diagrams

act ivity diagramssequence diagrams

di i

archit ect ureelement s

int erfaceelement s

component -levelelement s

deployment -levelelement s


process dimension

Design model elementsDesign model elementsData elements

Data model ‐‐ data structuresData model ‐‐ database architecture

Architectural elementsArchitectural elementsApplication domainAnalysis classes, their relationships, collaborations and behaviors aretransformed into design realizationsPatterns and “styles”

Interface elementsInterface elementsThe user interface (UI)External interfaces to other systems, devices, networks or other producers orconsumers of informationInternal interfaces between various design components

Component elementsComponent elementsDeployment elements


Software architectureSoftware architecture

The architecture is not the operational softwareThe architecture is not the operational software.Rather, it is a representation that enables asoftware engineer to:software engineer to:

Analyze the effectiveness of the design in meeting itsy g gstated requirements

Consider architectural alternatives at a stage whenConsider architectural alternatives at a stage whenmaking design changes is still relatively easy

Reduce the risks associated with the construction ofthe software.


Why is architecture important?Why is architecture important?Representations of software architecture are an enabler forRepresentations of software architecture are an enabler forcommunication between all parties (stakeholders) interested inthe development of a computer‐based systemp p y

The architecture highlights early design decisions that will haveThe architecture highlights early design decisions that will havea profound impact on all software engineering work thatfollows and, as important, on the ultimate success of the systemfollows and, as important, on the ultimate success of the systemas an operational entity

Architecture “constitutes a relatively small, intellectuallygraspable model of how the system is structured and how itsgraspable model of how the system is structured and how itscomponents work together” [BAS03]


Architectural StylesArchitectural StylesEach style describes a system category that encompasses:y y g y p

A set of components (e.g., a database, computational modules) that perform afunction required by a systemA set of connectors that enable “communication coordination and cooperation”A set of connectors that enable communication, coordination and cooperationamong componentsConstraints that define how components can be integrated to form the systemS ti d l th t bl d i t d t d th ll ti fSemantic models that enable a designer to understand the overall properties of asystem by analyzing the known properties of its constituent parts

Architectural Styles:Data‐centered architectures

Data flow architecturesData flow architectures

Call and return architectures

Object‐oriented architectures

Layered architectures


Data‐centered architectureData centered architecture


Data flow architectureData flow architecture


Call and return architectureCall and return architecture


Layered architectureLayered architecture


analysis and design - cinvestavertello/swe/sesion07.pdf · 2014-07-17 · analysis classes external...

Documents