1. Software Development Method, page 1 A Simple Software Method

2. Software Development Method, page 2 Software Engineering Methods modeling language and a processMost methods consist of both a modeling language and a process (who is doing what and when). visual languageThe modeling language, the notation, typically include some visual language (different types of diagrams). toolA tool to support the method is also crucial.

3. Software Development Method, page 3 UML Is Not a Process A “complete” development process defines: - Who is doing What, - When to do it, and - How to reach a certain goal The UML is intentionally process independentThe UML is intentionally process independent, and defining a standard process was not a goal of UML. Different domain may require different processes. But the UML authors promote a development process that is use- case-driven, architecture centric, iterative and incremental. (Example of method: RUP)

4. Software Development Method, page 4 The Management ProcessThe Management Process - schedules work, resources and deliveries, monitor progress. The Development ProcessThe Development Process - develop software from requirements. Software Development - Two Processes at the Same Time

5. Software Development Method, page 5 Since the management process controls project, risk it has to be paramount. Some methods contains both processes, e.g. RUPSome methods contains both processes, e.g. RUP, others are mostly development processes, like Catalysis, and others again are management processes, e.g. Dynamic Systems Development Method (DSDM). The Development Process is Subservient to the Management Process

6. Software Development Method, page 6 The waterfall model of software development Requirements Capture Purpose: communicate with end users and document the requirements. “Defining the right project”. Requirements Capture Purpose: communicate with end users and document the requirements. “Defining the right project”. Analysis Purpose: understand the problem domain and the system to be implemented. Analysis Purpose: understand the problem domain and the system to be implemented. Design Purpose: transform the products of the analysis phase into a more precise description that can be refined into an executable program. Design Purpose: transform the products of the analysis phase into a more precise description that can be refined into an executable program. Implementation Purpose: transform the products of the design phase into concepts that can be executed on the computer (programming). Implementation Purpose: transform the products of the design phase into concepts that can be executed on the computer (programming). Testing and Integration

7. Software Development Method, page 7 Requirements Capture functional and nonfunctionalThere are two types of requirements: functional and nonfunctional. Functional requirements is often modeled with use casesFunctional requirements is often modeled with use cases. A use case is a short story describing a particular use of the system - a model of a dialogue between an actor and the system.The model can be visualized with a use case diagram! a nonfunctional requirement:“the data is stored on ASCII files”Example of a nonfunctional requirement: “the data is stored on ASCII files”. user interfaceSometimes the user interface is developed or a prototype of the system is made.

8. Software Development Method, page 8 Analysis object analysis and behavior analysisThe analysis includes object analysis and behavior analysis. object analysis class diagramsIn object analysis all the key concepts related to the system are documented with the help of class diagrams. behavior analysis external functionality is modeledIn behavior analysis the system is model as a black box, only external functionality is modeled. A operation list is produced.

9. Software Development Method, page 9 Design deals with objects and functions that will be programmedDesign deals with objects and functions that will be programmed. classes extended with operationsThe classes from the analysis phase is extended with operations. Classes necessary for the implementation are added. operations are modeled with sequence diagramsThe operations are modeled with sequence diagrams. From the sequence diagrams we can see the responsibility of the different classes and how the classes interact.Design

10. Software Development Method, page 10 Static path use case 1 use case 2 Requirements class X attribut1....... operation 1 operation 2.... operation 1 operation 2.... Analysis Class Diagrams Operation Lists Test Cases use case 1 use case 2 void func1() {......}...... void func1() {......}...... Methods class X{.... }..... class X{.... }..... Implmentation Declarations class X attribut1.... method() Design Class Diagrams class Y attribut1.... Sequence Diagrams obj1 met1() Obj2 Functional path

11. Software Development Method, page 11 Iterative and incremental development. only a part is implemented through each cycleEach cycle consist of one or more of the process components (requirement, analysis,...), typically only a part (an increment) of the required functionality is implemented through each cycle. requirements are verified and validatedAt each cycle the requirements are verified and validated, this can lead to changed requirements. In each cycle the most risky functionality is addressedIn each cycle the most risky functionality is addressed, the cycle is aimed at eliminating the risk. In this way serious problems is exposed at an early stage, in some cases this can lead to termination of the project. RequirementsAnalysisDesignImplementationTestingRequirements.... First Cycle....

12. Software Development Method, page 12 Types of risks the right systemThe requirements do not specify the right system. technologynot adequateThe selected technology is not adequate for solving the given types of problems. right skillsPeople with the right skills are not available to the project. political forcesThere are political forces that will try to stop or delay the project.

13. Software Development Method, page 13 High-level view of the development phases InceptionInception - the vision of the project is specified. A go-ahead of the project is given. ElaborationElaboration - the project is planned. Features and architecture is elaborated. ConstructionConstruction - the system is developed through a series of iterations. TransitionTransition - the product is set in production. User training is given. In each phase the cycle of analysis, design, implementation and testing is preformed repeatedly.In each phase the cycle of analysis, design, implementation and testing is preformed repeatedly.

14. Software Development Method, page 14 The development process At each phase several complete cycles are possible. In the beginning requirements capture and analysis is focused, the other process components are more important later on. Inception R = Requirements A = Analysis D = Design I = Implementation T = Testing RARARADADIDITIT ElaborationConstructionTransition Example of development process:

15. Software Development Method, page 15 The Iconix Development Process

16. Software Development Method, page 16 Use Case Driven Object Modeling with UML tm : A Practical Approach by Doug Rosenberg and Kendall Scott

17. Software Development Method, page 17 Significant Features Iterative and Incremental. Traceability ~ you always refer back to the requirements. (Objects are there to satisify use cases.) A ”minimalist” approach - a minimal number of steps and use of diagram types.

18. Software Development Method, page 18

19. Software Development Method, page 19 Use Case Model Boundary1Entity1 Control1 Control2 Entity2 Robustness Diagram (Class Diagram) Design Class Diagrams Domain Model Class Diagrams Sequence Diagram obj1 met1() Obj2 1 User.. 2 … Use Case Text Ok Cancel GUI Prototype class AB attribut1.... class A attribut1.... class AA attribut1.... Dynamic Static

20. Software Development Method, page 20 Requirements Analysis Domain Modeling –Identify your real-world domain objects and the generalization and aggregation relationships among those objects. GUI design / Prototyping –If it’s feasible, do some rapid prototyping of the proposed system. (Mine your legacy software). ”…the best way to identify chunks of use cases in connection with a prototype is to write a rough user manual, as if the prototype were an actual fully working system.” Use Case Modeling –Identify your use cases. –Organize the use cases into packages. –Allocate functional requirements to the use cases and domain objects at this stage. class AB attribut1.... class A attribut1.... class AA attribut1.... Ok Cancel

21. Software Development Method, page 21 Analysis And Preliminary Design Write Use Case Text –Write describtion of the normal flow (also called main flow, the ”sunny day” scenario) and the alternate flows (extensions) Robustness Analysis. For Each Use Case: –Identify a first cut of objects that accomplich the selected scenario. –Update your domain model and your design class diagrams with new objects and attributes as you discover them. --- 1 --- EndUser chooses Tourism/ Environment --- 2 --- EndUser chooses fishing --- 3 --- …… Boundary1Entity1 Control1 Control2 Entity2 class AB attribut1.... class A attribut1.... class AA attribut1....

22. Software Development Method, page 22 Design Interaction Modeling (Allocate behavior). For Each Use Case: –Identify the messages that need to be passed between objects, the objects, and the associated methods to be involved. Draw a sequence (or collobaration) diagram with use case text running down the left side. Continue to update the design class diagram with attributes and operations as you find them. Sequence Diagram obj1 met1() Obj2 1 User.. 2 … Use Case Text

23. Software Development Method, page 23 Use Case Model Boundary1Entity1 Control1 Control2 Entity2 Robustness Diagram (Class Diagram) Design Class Diagrams Domain Model Class Diagrams Sequence Diagram obj1 met1() Obj2 class AB attribut1.... class A attribut1.... class AA attribut1.... Dynamic Static

24. Software Development Method, page 24 The use case model ~ heart of the approach Robustness analysis –What satisfy each use case? –Propose a set of collaborating objects that can solve each use case. Interaction modeling –Refine the results of robustness analysis. –Show how messages flow between the collaborating objects that solves each use case. The use case model is pumping through the following modeling activities.

25. Software Development Method, page 25 The Domain Modeling Is A Conceptual Model - Perspectives Conceptual Conceptual : The concepts of the problem domain are addressed. The class diagrams produced under the analysis will typically be of the conceptual type. The diagrams are not tied to any software implementation. Specification Specification : This perspective is closer to software. Interfaces is specified, but not the implementation. It is said that types are specified and not classes. This perspective is typically employed under design. Implementation Implementation : The class diagrams produced will reflect the classes that is to be implemented.

26. Software Development Method, page 26 Class objectstatebehavior a unique identification An object has three characteristics: state, behavior and a unique identification. A class is a template for instantiation of objects A class is a template for instantiation of objects. A class diagram contains an attribute (state) and a method (behavior) section: Class Name attribute: Type = initialValue.... method(arg list): return type.... It isusual to leave the method section out under analyses The level of and the numbers of details in the class diagram can vary, this depends on where you are in the development process. It is for example usual to leave the method section out under analyses.

27. Software Development Method, page 27 Discover Classes The high-level problem statement Lower-level requirements Expert knowledge of the problem space Use cases if already present

28. Software Development Method, page 28 Discover Classes Grammatical Inspection Noun Noun: a word that names or denotes something. E.g.: Fisher doesn’t know which river to choose…. FisherRiver Noun Phrases Noun Phrases: E.g.: Fisher selects a seasonal fishing license… FishingLicense cardType:String Nouns become objects Nouns Phrases become attributes

29. Software Development Method, page 29 Operations and Associations Grammatical Inspection Verbs Verbs: E.g.: He uses the localisation service to find his object in the service. Locator getObject() Verb Phrases Verb Phrases: E.g.: The user can use different devices … EndUser Verbs become operations Verb Phrases become associations Device uses

30. Software Development Method, page 30 Attributes Rather Than Objects Possessive Phrases Possessive Phrases: E.g.: A fishing card has a limited duration.. FishingCard Possessive Phrases indicate that nouns should be attributes rather than objects duration

31. Software Development Method, page 31 Robustness Diagram Symbols (Class Stereotypes) Control Class: Control Class: Manage interactions. Its behavioir is specific to a use case, which it usally does not outlive. Boundary Class: Boundary Class: Mediate between the system and outside actors (e.g. sensor). Often their lifeline coincide with the life of the system. Entity Class: Entity Class: Passive objects, they do not initiate interactions. May participate several use cases.

32. Software Development Method, page 32 Robustness Diagram Rules Allowed Not Allowed

33. Software Development Method, page 33 [1] ”…you’re not finished with a use case until the text and the robustness diagram match.” Use Case ~ Robustness

34. Software Development Method, page 34 References Grady Booch, James Rumbaugh and Ivar Jacobson: The Unified Modeling Language User Guide. Addison-Wesley, 1999 James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy and William Lorenzen: Object-Oriented Modeling and Design. Prentice Hall, 1991 Martin Fowler with Kendall Scott: UML Distilled. Addison-Wesley, 1997 Terry Quatrani: Visual Modeling with Rational Rose and UML. Addison-Wesley, 1998 Ari Jaaksi: A Method for Your First Object-Oriented Project. JOOP - The Journal of Object-Oriented Programming, Januar 1998 Rational software: http://www.rational.com/uml/documentation.html http://www.rational.com/uml/documentation.html [1] Doug Rosenberg and Kendall Scott: Use Case Driven Object Modeling with UML: A Practical Approach Addison-Wesley