Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
6/28/2005 Software Engineering 1
Software Process Modelling
M. Letizia Jaccheri (NTNU)
Fernando Brito e Abreu (FCT/UNL)
Software Engineering 26/28/2005
OverviewSw Process Modelling Languages (PMLs)
General issuesMeta-ProcessProcess ElementsCharacteristics of languagesRelated domainsArchitectural issuesSurvey of PMLsModelling exampleRUP
Software Engineering 36/28/2005
General issues: FormalityFormal PML
syntax and semantics
Semi formalsyntax
InformalEnglish: Analysis must finish before design starts. R1
is responsible for Analysis and R2 is responsible for Design. Analysis produces D1 and Design produces D2
AnalysisDesign
R1
R2
D2
D1
Analysis Design
R1
D2D1
R2
Software Engineering 46/28/2005
General issues:Processes and Models
Modelled world
Real worldProject
Project Manual
Quality Manual
ModelTemplate
is_derived_from
is_instantiated_into
Software Engineering 56/28/2005
Why do we need process models?Facilitate human understanding and communicationSupport process changeSupport process managementAutomate process guidanceAutomate execution supportCASE tools coordination (process-aware)
Software Engineering 66/28/2005
Why do we need process models?Enterprise modelling is becoming a common practice, mainly due to ISO9001 certification purposes
It allows detecting, among other things, task inputs/outputs which are not connected Often practitioners “invent” informal flow notations
Terje Totland, Enterprise Modeling as a Means to Support Human Sense-making and Communication in Organizations, IDI, NTNU, PhD thesis 1997
Software Engineering 76/28/2005
Meta-ProcessElicitation
process as it is versus what it should be
Analysissimulate, verify, check
Designprocess architecture, planning, quality models
Implementationcode in a formal PML
Enactmentautomatic and manual
Assessmentquality and performance
Software Engineering 86/28/2005
Process Elements
Modelled world
persons
toolrole human
productactivity
Real world
Processtools
projectEvolutionsupport
filestools workspace
Software Engineering 96/28/2005
Process ElementsActivityProductHuman RoleToolEvolutionProjectsWork context
Tool viewUser ViewCooperationVersioningMetrics
Software Engineering 106/28/2005
Characteristics of languagesFormalityExpressivenessAbstraction and modularizationExecutabilityAnalysabilityGraphical representation / multiple views
Software Engineering 116/28/2005
Related domainsProject management
Gantt chart, activity networks (CPM)Formal specification languages
Petri net, CSP, Prolog, etc..Informal design notations
Extended E-R, OMT, UML Programming languages
Ada, Eiffel…
Software Engineering 126/28/2005
Related domains (2)Data base languages
AdeleCase tools
Spade uses DecFuse ++WorkFlow and Groupware
Role Interaction diagram, groupware ++
Software Engineering 136/28/2005
Architectural Issues
Process model Processmodelling
tool ProcessmodellerProcess
engine
Processactor
Workspace
Software Engineering 146/28/2005
PML Survey: Adele
ADELE-DB at LGI in GrenobleHas versioning, own DDL/DML with dynamically bound schema and triggers, nested short transactions, and workspace supportADELE-TEMPO offers object roles (dynamic types) and process interconnectionslater APEL high-level graphical PML
Software Engineering 156/28/2005
PML Survey: EPOSNTNU (ex-NTH) in TrondheimUniformly versioned EPOSDB Reflexive process models model in SPELL (Prolog)BMS-connected tools
Software Engineering 166/28/2005
PML Survey: SPADEPolitecnico di MilanoProcess model is a generalised and reflexive Petrinet with tokens denoting OO products, all stored in O2Tool/user communication separately via a BMS (DEC-FUSE).
Software Engineering 176/28/2005
PML Survey:Process Weaver (now FlowWeb)
Cap Gemini (Grenoble)Process model is an extended Petri netActivity modelling by project clusters, with file workspaces and BMS-connected tools.Set of tools to help organizing and supporting the work of a group of people. Allows to define the methods at company and project level and the work organizationHas project management tool connectivity
Software Engineering 186/28/2005
Software Engineering 196/28/2005
Software Engineering 206/28/2005
PML Survey: Process Wise IntegratorICLRole-activity-interaction paradigm, strong on evolutionRoles represent humans or toolsPML is translated to PS-Algol
Software Engineering 216/28/2005
PML Survey: SoccaRijksuniversiteit Leidenclass diagram for data perspective, state transition diagram for behaviour, and Paradigm for communicationmain goal: communication and analysis
Software Engineering 226/28/2005
PML Survey: AlfUniversity of Nancy Loria5 sub-languages
RulesERconstraintscharacteristics (logic)tool description
Software Engineering 236/28/2005
PML Survey: MerlinUniversity of DortmundProlog ruleslater Escape for modelling
Software Engineering 246/28/2005
PML Survey: PeaceUniversity of Savoie at AnnecyEnactable knowledge representation languagereflection and reification
Software Engineering 256/28/2005
PML Survey: IDEF0IDEF (Integrated DEFinition Method) is a popular public domain notation in use for more than 25 years.Commissioned by the United States Air ForceSemi formal notation based on Structured Analysis and Design Technique (SADT)In December 1993, the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST) released IDEFØ as a standard for Function Modelling in FIPS Publication 183.within the frame of FEO (For Exposition Only) Preconditions Actions and Postconditions were added
http://www.idef.com/overviews/idef0.htm
Software Engineering 266/28/2005
IDEF0 tool: WorkFlow Analyzer Produced by Meta Software Corporation
http://www.metasoftware.com/Mainly used for BPRHas a repository and simulation tool based on IDEF0.IDEF0 is used for process modeling IDEF1X is used for data descriptionWorks in conjunction with WorkFlow Modeler
Software Engineering 276/28/2005
IDEF0 Tool: WorkFlow Modeler
Software Engineering 286/28/2005
PML Survey: E3
Politecnico di TorinoObject oriented notation enhanced to facilitate process-modelling activitiesElicitation and analysis, no enactionprocess template (classes and associations)process model instance
Class, attributes, and method signatures Aggregations, associationsObject, set of attribute valuesLinks
Software Engineering 296/28/2005
subtask
aggregation
association
preorder
use
responsibleoutput
input
PML Survey: E3
Software Engineering 306/28/2005
Modeling example: Olivetti process
The main phases of the Olivetti design process are market analysis, product design (including the development of prototypes), and production lines design.
The design of a new hardware product consists of a feasibility study and a development phase. The development phase, in turn, encompasses hardware, firmware, and cabinet design and development, along with software development, prototyping, and production of the documentation.
Software Engineering 316/28/2005
Performance prediction. This activity is centered on the development of a performance model of the hardware to be developed. The performance model is very critical since it is used in all the following phases to evaluate the effectiveness of the design choices taken during the course of the project.Logic function design. The result of this activity is the logical design of the electronic components of the new hardware. It defines the partitioning of the different functions on the PC boards and the corresponding allocation of digital chips and circuits. An important by-product of this activity is the preliminary definition of the bill of material.
Olivetti process (continued)
Software Engineering 326/28/2005
Simulation. It is centered on the evaluation of the overall product performance and characteristics, based on the different models produced in the previous activities.Production and supplying analysis. This activity aims at defining the needs and requirements related to the mass production of the new product. It is centered on the selection of the specific components to be used (and related suppliers), and also on the analysis and design of specific technical solutions that can reduce the complexity of the production process and increase the reliability and overall quality of the delivered product.
Olivetti process (continued)
Software Engineering 336/28/2005
Detailed design of the product. Each component of the new PC is designed using a CAD environment. This includes, for instance, the detailed design of each board, and the definition of the mechanical parameters related to the assembly of the final products (e.g., hole diameters and flange dimensions of the PC box).Board production. The assembly of the initial prototypes of the new hardware requires the availability of a set of pre-production boards and components. The development of these parts is delegated to external specialized companies.
Olivetti process (continued)
Software Engineering 346/28/2005
Testing. Each component of the pre-production series undergoes an extensive testing activity. The testing activity is then extended to the assembled prototypes.
The final outcome of the hardware design phase is the release of the documentation and directives for the production line.
Olivetti process (continued)
Software Engineering 356/28/2005
Software Engineering 366/28/2005
Software Engineering 376/28/2005
Rational Unified Process (RUP)
Rational Approach Objectory Process 3.81995
IBM - Rational Unified Process v2003
2003
Rational Objectory Process 4.01996 OMT approach UML 0.5
OOSE
Rational Unified Process 5.01998
Performance TestingBusiness EngineeringData Engineering
Objectory UI DesignChange & Configuration Management
UML 1.2
Rational Objectory Process 4.11997 Requirements
CollegeSQA ProcessUML 1.0
Software Engineering 386/28/2005
Analysis Model
Specified by
Deployment Model
Distributed by
Design Model
Realized by
Implementation Model
Implemented by
XOK
XOK
XOK
Test Model
Verified by
Use-Case Model
Rational Unified Process (RUP)
Software Engineering 396/28/2005
Rational Unified Process (RUP)
(When)
Workflow
(What)
(Who) (How)