Software Engineering 1 Software Engineering Methods Most methods

Software Engineering 1

Software Engineering Methods • Most methods consist of both a modeling language and a process (who is doing what and when). • The modeling language, the notation, typically includes some visual language (different types of diagrams). • A tool to support the method is also crucial. 2

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 independent, 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) 3

Software Development – Two Processes at the Same Time • The Management Process - schedules work, deliveries and resources, monitor progress. • The Development Process - develop software from requirements. • The management process is controlling the development process. • Some methods contains both processes, e. g. RUP; RUP others are mostly development processes, like Catalysis, and others again are management processes, e. g. Dynamic Systems Development Method (DSDM). 4

The waterfall model of software development Requirements Analysis and Capture Purpose: understand the problem domain and the system to be implemented; communicate with end users and document the requirements. 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. Unit testing. Testing and Integration System Testing Operation and Maintenance 5

Requirements Analysis and Capture - 1 A requirement is a wanted property or behavior of a system. There are two types of requirements: – Functional – Nonfunctional 6

Requirements Analysis and Capture - 2 Functional Requirements • Functional requirements are often modeled with use cases – A use case is a short story describing a particular use of the system; a dialogue between an actor and the system. – Visualized with a use case diagram and a descriptive text! • Sometimes the user interface is developed or a prototype of the system is made. 7

Requirements Analysis and Capture - 3 Nonfunctional Requirements • Reliability (Nonfunctional requirements) • Maintainability (Nonfunctional requirements) • An example of a nonfunctional requirement: “the data should be stored on ASCII files”. 8

Perspectives • 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: 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: The class diagrams produced will reflect the classes that is to be implemented. 9

Requirements Analysis and Capture - 4 Domain Model a Conceptual Model • When your making a domain model you capture the key concepts of the problem domain ~ “things”, the real world concepts (domain concepts/the context of the system). • Purpose: describe and understand the main concepts within the domain and how these concepts relates to each other and the systems context (On the other hand when you make a design model you specify the software types/classes you need to solve the problem). • A domain model is typically visualized with class diagrams (sometimes collaboration diagrams, state charts). . 10

Reality Domain Model The Domain Concepts From The Domain Person owner Car DESCRIBE AND UNDERSTAND THE MAIN CONCEPTS WITHIN THE DOMAIN 11

Requirements Analysis and Capture - 5 Domain Model A Simple OO Model • The domain model is less detailed and precise than the design model The model is a sort of “thinking model”[1] and some recommend it to be kept simple (you might restrict your self to a subset of the UML notation). • The same domain model may be used as basis for many applications – it is a platform independent model (PIM). • Often there is a glossary of terms that describes the domain classes and other classes (the domain model should not be to large). It is important to have a common vocabulary! vocabulary • [1] You should keep the latest version of this model even when you shift focus to design, implementation, … 12

Design • Design deals with objects and functions that will be programmed • The classes from the analysis phase is extended with operations Classes necessary for the implementation are added. • The operations can be modeled with sequence diagrams. From the sequence diagrams we can see the responsibility of the different classes and how the classes interact. 13

Design Implementation Model • The design ends up with an implementation model. • There are tools that can map from this model to code • The implementation is a full specification of the system • You can trace back from this model to the models on higher levels of abstraction 14

Relationships Between The Different Models • The number of models and which abstraction levels to operation on is a matter of choice – there is no complete “right or wrong“. • The larger (complex) the system, the more time should be spent on modeling. • Generally: – You go from more abstract models and end up with implementation models. – More and more details are added. – You go from more logical models to more concrete ones. – You go from a user point of view to an implementation point of view. 15

Models – An Example • Domain Model (conceptual model): – Concepts of the domain (real world classes) – Analysis (requirement) • Type Model (conceptual/specification model): – Software types that should be covered by the system – Analysis / preliminary design • Design Model (specification): – Classes (with operations) that will be implemented • Implementation Model: – A fully specified system that can be mapped to code 16

What is needed in the system Analysis Model How should the system work Domain Model (an analysis model) Design Model Understand Refine Implementation Model Map to code Problem Domain Code / Implemented System Install 17

Static path Requirements Analysis and Capture Use Cases use case 1 Domain Model class X attribut 1. . Design Implementation Design level Diagrams Coding class X class Y attribut 1. . . . class X{. . }. . . method() Testing Test Cases use case 1 use case 2 Use Case Texts <x>does<y>. . Methods Sequence Diagrams obj 1 Obj 2 met 1() void func 1() {. . . }. . . Functional path 18 use case 2

Iterative Development • [2] “The waterfall method should only be used when the requirements are well understood and unlikely to change radically during system development. ” • [1] “As the developer work with a system and understand it better, the model must be iterated at all levels to capture that understanding; it is impossible to understand a large system in a single, linear pass. ” 19

Iterative and incremental development. • Each cycle consist of one or more of the process components (requirement, design, . . . ), typically only a part (an increment) of the required functionality is implemented through each cycle. • At each cycle the requirements are verified and validated, this can lead to changed requirements. • In 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. Requirements / Analysis Design Implementation First Cycle 20 Testing Requirements . . . .

Types of risks • The requirements do not specify the right system. • The selected technology is not adequate for solving the given types of problems. • People with the right skills are not available to the project. • There are political forces that will try to stop or delay the project. 21

High-level View Of The Development Phases • Analysis, design, … are called modeling stages, this are not synchronized with the development phases. • Inception - the vision of the project is received; initial ideas are discussed; a go-ahead of the project is given. • Elaboration - the project is planned. Features and architecture is elaborated. • Construction - the system is developed through a series of iterations. • Transition - the product is set in production. User training is given. • In each phase the cycle of requirement, design, implementation and testing (the modeling stages) is preformed repeatedly. 22

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. / R/A = Requirements Analysis D = Design I = Implementation T = Testing Example of development process: R/A R/A D Inception Elaboration A D I Construction 23 D I T Transition

References • • [1] James Rumbaugh , Ivar Jacobson, Grady Booch: The Unified Modeling Language Reference Manual. Addison-Wesley, 1999 [2] Ian Sommerville: Software Engineering, Eight Edition. Addison-Wesley, 2007 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 24