Seminal Object-Oriented Methodologies-Software Development Methodologies- Lecture 4 Slides-Computer Engineering, Slides of Software Development Methodologies

Download Seminal Object-Oriented Methodologies-Software Development Methodologies- Lecture 4 Slides-Computer Engineering and more Slides Software Development Methodologies in PDF only on Docsity!

Software Development Methodologies Lecturer:^ Raman Ramsin^ Lecture 4^ Seminal Object-Oriented Methodologies:A Feature-Focused Review^

(Part 2) Department of Computer Engineering^

Sharif University of Technology 1

Software Development Methodologies – Lecture 4 Object-Oriented Software Engineering (OOSE)j^

g^ g (^ )

„^ First introduced by Jacobson et al. in 1992 „^ A^ simplified^ version

of^ Jacobson’sObjectorymethodology, first introduced in 1987 and later themethodology, first introduced in 1987 and later theproperty of Rational Corporation (now acquired byIBM)IBM) Covers the full generic lifecycle

„^ Covers^ the full generic lifecycleDepartment of Computer Engineering^

Sharif University of Technology 2

Software Development Methodologies – Lecture 4 OOSE: Process „^ Analysis:^ focusing^ on^ understanding

the^ system^ and^ creating^ a conceptual model. Consists of two non-sequential, iterative subphases:^ ^ Requirements Analysis, aiming at eliciting and modeling the requirements ofthe system. ARequirements Model is produced.^ ^ Robustness Analysis, aiming at modeling the structure of the system. AnA^ l^ i^ M d l i^ d^ dAnalysis Model is produced. „ Construction:^ focusing^ on^ creating

a^ blueprint^ of^ the^ software^ and producing the code^ Consists of two subphases:producing the code. Consists of two subphases:^ ^ Design, aiming at modeling the run-time structure of the system, and also theinter-object and intra-object behaviour. A

Design Model is produced.j jg^ p

^ Implementation, aiming at building the software. An

Implementation Model (including the code) is produced.T ti^ f^ i^ if i^ d^

lid ti^ th^ i^ l^ t d^ t „^ Testing: focusing on verifying and validating the implemented system.ATest Model is produced.Department of Computer Engineering^

Sharif University of Technology 3

Software Development Methodologies – Lecture 4 OOSE: Process Department of Computer Engineering^

[Jacobson et al. 1992]Sharif University of Technology 4

Software Development Methodologies – Lecture 4 OOSE: Analysis – Requirements Analysisy^ q^

y

„^ Aim:^ Specify^ and^ model

the^ functionality^ required^

of^ the p^ y^

y^ q system,^ typical^ means^ and

forms^ of^ interacting^ with

the system, and the structure of the problem domain. „ The model to be developed is the

Requirements Model, further

divided into three submodels:divided into three submodels:^ ^ AUse^ Case^ Model:^ which^ delimits

the^ system^ and^ describes^ the f^ i^ l^ i^ f^ h^

’^ i functional requirements from the user’s perspective. ADomain^ Object^ Model:^ consists

of^ objects^ representing^ entities derived from the problem domain, and their

inheritance, aggregation andassociation relationships. Interface Descriptions: provide detailed logical specifications of theuser interface and interfaces with other systems.Department of Computer Engineering^5

y Sharif University of Technology

Software Development Methodologies – Lecture 4 OOSE: Analysis - Requirements Modely^ q Use Case Model Department of Computer Engineering^

[Jacobson et al. 1992]Sharif University of Technology 6

Software Development Methodologies – Lecture 4 OOSE: Analysis - Requirements Modely^ q Domain Object ModelDomain^ Object Model Department of Computer Engineering^

[Jacobson et al. 1992]Sharif University of Technology 7

Software Development Methodologies – Lecture 4 OOSE: Analysis – Robustness Analysisy^

y

„^ Aim: Map theRequirements Model to a logical configuration of thesystem that is robust and adaptable to change.y^

p^ g „^ The model to be developed is the

Analysis Model:

^ Shows how^ the^ functionality^ of each

and every^ use^ case^ is realized^ by

^ Shows^ how^ the^ functionality^ of each

and every^ use^ case^ is realized^ by collaboration among typed objects (called

Analysis Objects).

^ Shows the subsystems of the system. „^ Analysis Objects can be of three types: ^ Entity: Represent entities with persistent state, typically outliving the usecases they help realize. They are usually derived from the domain objecty^ p^ y^

y^ j model. Interface: Represent entities that manage transactions between the systemand the actors in the outside world. Control: Represent functionality not inherently belonging to other types of Control: Represent functionality not inherently belonging to other types ofobjects. They typically act as controllers or coordinators of the processinggoing on in the use cases.Department of Computer Engineering^8

Sharif University of Technology

Software Development Methodologies – Lecture 4 OOSE: Analysis - Analysis Modely^ y Analysis ModelAnalysis^ Model Department of Computer Engineering^

[Jacobson et al. 1992]Sharif University of Technology 9

Software Development Methodologies – Lecture 4 OOSE: Construction - Design

g

„^ Aim: Refine theAnalysis Model by taking into accountimplementation features. „^ The model to be developed is the

Design Model:

^ describes the features of the implementation environment ^ describes the details of the design classes (referred to as ^ describes the details of the design classes (referred to asblocks) necessary to implement the system ^ describes the way run-time objects should behave and ^ describes the way run time objects should behave andinteract in order to realize the use casesDepartment of Computer Engineering^10

Sharif University of Technology

Software Development Methodologies – Lecture 4 OOSE: Construction - Design

g

„^ Three Subphases:1.^ Determination of the features of the implementation environment(DBMS,^ programming

language^ features,^ distributionconsiderations,…), ) 2. Definition ofblocks (design classes) and their structure:Each object in the Analysis Model is mapped to ablock1. Each object in the Analysis Model is mapped to ablock.2. Implementation-specific blocks are added and the collection is revised.3. Interfaces and semantics of operations are defined.3. Specification of the sequences of interactions among objects and thedynamic behaviour of each block:1. AnInteraction Diagram is drawn for each of the use cases.2. AState Transition Graph is used for describing the behaviour of eachblock. Department of Computer Engineering^

Sharif University of Technology 11

Software Development Methodologies – Lecture 4 OOSE: Construction - Design Model

g

Interaction Diagram Department of Computer Engineering^

[Jacobson et al. 1992]Sharif University of Technology 12

Software Development Methodologies – Lecture 4 OOSE: Construction - Implementationp „^ Aim: Produce the code from the specifications of thepackages and blocks defined in the design model.p^ g^

g

„^ The model to be developed is the

Implementation

„^ The model to be developed is the

Implementation

Model, which consists of the actual source code andaccompanying documentationaccompanying documentation.Department of Computer Engineering^13

Sharif University of Technology

Software Development Methodologies – Lecture 4 OOSE: Testingg „^ Aim: Verify and validate the implementation model „^ The model to be developed is the

Testing Model, which

i l^ i t^ fmainly consists of: Test plan Test specifications Test specifications Test results. „ Testing is done at three levels, starting from the lowestlevel: blocks are tested first Use cases are tested next Finally^ tests are performed on the whole systemDepartment of Computer Engineering^14

Sharif University of Technology

^ Finally, tests are performed on the whole system

Software Development Methodologies – Lecture 4 OOSE: Pivotal role of the Use Case Model Department of Computer Engineering^

[Jacobson et al. 1992]Sharif University of Technology 15

Software Development Methodologies – Lecture 4 Business Object Notation (BON)j^

(^ )

Fi^ t^ i t^ d^ d^ b^ N^

i^1992 ti l^ with^ the „^ First^ introduced^ by^ Nerson

in^ a^1992 article,^ with^

the

acronym standing for “Better Object Notation” „ A revised and detailed version of the methodology wasput forward in 1995; this time the acronym stood for“Business Object Notation”“Business Object Notation”. „ The process spans the analysis and design phases of the„ The process spans the analysis and design phases of thegeneric software development lifecycle. „ Deeply influenced by Eiffel’s assertion mechanisms andthe notion ofDesign by ContractDepartment of Computer Engineering^16

Sharif University of Technology

Software Development Methodologies – Lecture 4 BON: Process „^ Consists of nine steps, or tasks. „^ Tasks 1-6 focus on analysis and tasks 7-9 deal with design. Department of Computer Engineering^

[Walden and Nerson 1995]Sharif University of Technology 17

Software Development Methodologies – Lecture 4 BON: Products Department of Computer Engineering^

[Walden and Nerson 1995]Sharif University of Technology 18

Software Development Methodologies – Lecture 4 BON: Products Department of Computer Engineering^

[Walden and Nerson 1995]Sharif University of Technology 19

Software Development Methodologies – Lecture 4 BON: Products Department of Computer Engineering^

[Walden and Nerson 1995]Sharif University of Technology 20

Software Development Methodologies – Lecture 4 Hodge-Mockg „^ First introduced in a 1992 article „^ Result of research to find an OO methodology for use in asimulation^ and^ prototyping

laboratory,^ striving^ to^ introducehigher levels of automation^ into^ Air^ Traffic^ Control^

(ATC)

higher^ levels^ of^ automation

into^ Air^ Traffic^ Control^ (ATC) systems „ Extremely^ rich^ as^ to^ the^

types^ of^ diagrams^ and^ tables produced during the development process „ Due to strong mapping relationships among them, versions ofmost diagrams and tables are directly derivable from thoseinitially producedinitially produced. „ Spanning the full generic lifecycle Department of Computer Engineering^21

Sharif University of Technology Spanning^ the full generic lifecycle

Software Development Methodologies – Lecture 4 Hodge-Mock: Processg „^ Analysis: focus on defining the requirements and identifying the scope,structure and behaviour of the system. Consists of four subphases:R^ i^ t^ A^ l^ i^ ith th

f^ li iti^ th^ i^ t Requirements Analysis: with the focus on eliciting the requirements Information Analysis: focus on determining the classes in the problem domain,interrelationships, and collaborations among their instances Event Analysis: focus on identifying the behaviour of the system through Event Analysis: focus on identifying the behaviour of the system throughviewing the system as a stimulus-response machine Transition to System Design: focus on providing a more detailed view of thecollaborations among objects „^ System^ Design:^ with^ the^ focus

on^ adding^ design^ classes^ to^ the

class structure of the system and refining the external behaviour of each classS ft^ D^ i^ ith th^ f^

ddi^ i^ l^ t ti^ ifi^ l „^ Software Design: with the focus on adding implementation-specific classesand details to the class structure of the system, and specifying the internalstructure and behaviour of each class „^ Implementation: with the focus on coding and unit testing„^ Implementation: with the focus on coding and unit testing „^ Testing: focusing on system-level verification and validationDepartment of Computer Engineering^

Sharif University of Technology 22

Software Development Methodologies – Lecture 4 Hodge-Mock: Processg Department of Computer Engineering^

[Hodge and Mock 1992]Sharif University of Technology 23

Software Development Methodologies – Lecture 4 R fReferences^ J^ b^ I^ Ch i t^ M^ J

P^ Ö^ d^ G^ Obj^

t „^ Jacobson, I., Christerson, M., Jonsson, P., Övergaard, G.,

Object- Oriented Software Engineering: A Use Case Driven Approach.Addison-Wesley, 1992. „ Walden, K., Nerson, J.,Seamless Object-Oriented SoftwareArchitecture^ Prentice-Hall^1995 Architecture. Prentice-Hall, 1995. „ Hodge, L. R., Mock, M. T., “A proposed object-oriented developmentg ,^ ,^ ,^ ,^ p^

p^ j^ p methodology”.Software Engineering Journal, March 1992, pp. 119-129. Department of Computer Engineering^

Sharif University of Technology 24