Software Development Process Using UML Recap

1. Software Development ProcessUsing UML Recap

2. Software Development ProcessBird’s Eye View • UML is a Notation/Language • Need a Software Development Process using UML concepts • Many Development methods available or to come (Fusion, CRC, Catalysis, Rational Unified Process, …) • Method are more or less formal and heavy depending of type of project • Need to adapt Process Framework to project specific needs • Use-Case Driven, Architecture-Centric, Iterative, Incremental

3. Overall Process • Business Model using Activity Diagram • Requirements capture using Use Case Diagram • Planning by Use CasePrioritization • Requirements Analysis using Use Case Details and Class Diagram • Initial Design using Sequence Diagram andsecondversionof Class Diagram • Requirements Analysis using State Diagram • Architecture Design using Packages (with Visibility) and Subsystems • Design using next level of details for Class Diagram

4. Overall Process (cont.) • System Architecture using Deployment Diagram • Design using Design Patterns • Detail Design using Collaboration Diagram • Consolidate all information into Class Diagram • Detail Design using Component Diagram • Refine all models through iterations. • Implement the models by translating into code. • Deploy software within operational environment.

5. Requirements • List candidate requirements • textual feature list • Understand system context • domain model describing important concepts of the context • business modeling specifying what processes have to be supported by the system • Capture functional and nonfunctional requirements • Use Case Model • Supplementary requirements • physical, interface, design constraints, implementation constraints

6. Requirements Capture

7. Use Case Model • Model of the system's intended functions and its surroundings • Serves as contract between customer and developers. • Serve as a unifying thread throughout system development. • Result of the Requirements workflow • Used as input to Analysis & Design and Test workflows.

8. Detail Use Cases • Start with a short, step-by-step description of the use-case flow of events, and gradually make it more detailed. • Describe how the use case start and what is the signal that activates the use case. • Describe how the use case terminate • Describe what will reside inside the system, and what will reside outside the system.

9. Detail Use Cases (cont.) • Describe the interaction between use case and actors. • Describe how the use case exchange data with an actor. • Describe any optional situations in a use case's flow of events

10. Use Case Details • Name • The name of the use case. • Brief Description • A brief description of the role and purpose of the use case. • Flow of Events • A textual description of what the system does in regard to the use case. Understandable by the customer. Include the main flow of events as well as the alternate flow of events • Special Requirements • A textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation.

11. Use Case Details • Preconditions • A textual description that defines the state of the system prior to the use case may being performed. • Postconditions • A textual description that defines a list of possible states the system can be in immediately after a use case has finished. • Extension points • A list of locations within the flow of events of the use case at which additional behavior can be inserted using the extend-relationship. • Relationships • The relationships, such as communicates-associations, include-, generalization-, and extend-relationships, in which the use case participates.

12. Prioritize Use Cases • Goals: • Define the set of scenarios and use cases to be implemented in each iteration. • Prioritization • Define the set of scenarios and use cases that represent some significant, central functionality. • Define the set of scenarios and use cases that have a substantial architectural coverage or that stress or illustrate a specific, delicate point of the architecture. • Assess which use cases help mitigate high risk items

13. Requirements Artifacts

14. Analysis

15. Analysis • Analyze in depth the requirements: Scenario Diagram from Use Cases • Structure the Use Cases • Start reasoning about the internal of the system • Develop Analysis Model: Class Diagram and State Diagram • Focus on what is the problem not how to solve it • Understand the main concepts of the problem • Three main types of classes stereotypes may be used: • Boundary Classes: used to model interaction between system and its actors • Entity Classes: used to model information and associated behavior deirectly derived from real-world concept • Control Class: used to model business logic, computations transactions or coordination.

16. Object Modeling • Goals: • Identify the key abstractions that the system must handle. • Identify the classes which perform a use case’s flow of events. • Distribute the use case behavior to those classes, using use-case realizations. • Identify the responsibilities, attributes and associations of the classes.

17. Find Classes from Use Cases • Find Boundary Classes User interface classes classes which intermediate communication with human users of the system System interface classes classes which intermediate communication with other system Device interface classes classes which provide the interface to devices (such as sensors), which detect external events • Find Entity Classes stores of information in the system typically used to represent the key concepts • Find Control Classes Control classes provide coordinating behavior in the system

18. Enforce Consistency • For each new class found, make sure that there is no other class with same responsibility • As new classes are found, ensure they have consistent and unique responsibility. Otherwise split the object into two • A class with only one responsibility is not a problem, per se, but it should raise questions on why it is needed. • Be prepared to challenge and justify the existence of all classes.

19. Design

20. Design • Refine the Class Diagram • Structure system • Subsystems, Interfaces, Classes • Define subsystems dependencies • Capture major interfaces between subsystems • Assign responsibilities to new design classes • Describe realization of Use Cases • Use Sequence and Collaboration Diagrams • Assign visibility to class attributes • Define Methods signature • Develop State diagram for relevant design classes • Use Interaction Diagram to distribute behavior among classes • Use Design Patterns for parts of the system

21. Architectural Design • Identify Design Mechanisms • Refine Analysis based on constraints imposed by implementation environment • Characterize needs for specific mechanisms (inter-process communication, real-time computation, access to legacy system, persistence, …) • Assess existing implementation mechanisms • Identify Design Classes and Subsystems • A Subsystem is a special kind of Package which has behavioral semantics (realizes one or more interfaces) • Refine analysis classes • Group classes into Packages • Identify Subsystems when analysis classes are complex • Look for strong interactions between classes in Collaboration Diagrams • Try to organize the UI classes into a subsystem • Separate functionality used by different actors in different subsystems • Separate subsystems based on the distribution needs • Identify Interfacesof the subsystems

22. Implementation

23. Implementation Purpose • Define organization of code, in terms of implementation subsystems • Implement classes and objects in terms of components • source files, binaries, executables, and others • Test the developed components as units. • Integrate results produced by individual implementers (or teams), into an executable system

24. Implementation Process • Create the Initial Implementation model structure • Adjust Implementation Subsystems • Decide where to place Executables • Define Imports for each implementation subsystems • Decide wher to place test subsystems and components • Update the Implementation View • Evaluate the Implementation Model

25. Implementation/Integration • Distribute the system by mapping executable components onto nodes in the deployment model • Implement Design Classes and subsystems through packaging mechanism: • package in Java, Project in VB, files directory in C++ • Acquire external components realizing needed interfaces • Unit test the components • Integrate via builds

26. Testing

27. Testing • The purposes of testing are: • To verify the interaction between objects. • To verify the proper integration of all components of the software. • To verify that all requirements have been correctly implemented. • To identify and ensure defects are addressed prior to the deployment of the software

28. Testing • Develop set of test cases that specify what to test in the system • many for each Use Case • each test case will verify one scenario of the use case • based on Sequence Diagram • Develop test procedures specifying how to perform test cases • Develop test component that automates test procedures

29. Deployment • Producing the Software • Output of implementation is tested executables. • Must be associated with other artifacts to constitute a complete product: • Installation scripts • User documentation • Configuration data • Additional programs for migration: data conversion. • In some cases: • different executables needed for different user configurations • different sets of artifacts needed for different classes of users: • new users versus existing users, • variants by country or language • For distributed software, different sets may have to be produced for different computing nodes in the network

30. Deployment • Packaging the Software • Distributing the Software • Installing the Software • Migration • Providing Help and Assistance to Users • Acceptance