Silicomp Lessons: Requirements Capture & System Design

1. The Silicomp experience A summary of lessons learnt By Katarina Sigerud SL/CO/AP

2. The process • Requirements capture • Define what the system is • Define the actors • Find the use cases • Find the primary use cases – those that motivate the creation of the system • Prioritize in what order to do them • Detail these use cases with description and sequence diagram • Read through them to see if they make sense, that there are no inconsistencies (can be done during the detailing) • Analysis • Design

3. The system • Define the system • Create a domain model • Ask questions • Where is it used? • Why is it there? • What is around? • What is not in the system? • Who are the actors? • What are the use cases?

4. Ex (1/13): IH • Domain model

5. Actor • An actor initiates communication with the system • Difference from external system • Not in the system, but interacts with it • An actor has use cases • A primary actor is attached to a primary use case • Another definition: The actor who gains something is a primary actor. Use cases attached to this actor is then primary

6. Expected result From the actor’s point of view Triggering event What starts the flow – the reception of a message From the system’s point of view Precondition Must be met for the use case to start End condition What makes the use case stop From the system’s point of view Post condition What has changed for the system Use case (1/2)

7. Use case (2/2) • A use case must have interaction between an actor and the system • Difference from function • When the triggering event is not enough to distinguish between use cases • ‘Implement the use case’ – the dedicated code (i.e. the code that tells what use case we’re currently in) is usually put in the user interface

8. Ex (2/13): IH requirements capture • Use case diagram

9. Ex (3/13): IH requirements capture • Use case description Add recipe [Expected result] The recipe is added, available, and enabled. [Triggering event] The IH receives a recipe. [Precondition] None. [End condition] The recipe has been installed. [Post condition] The IH has one more recipe.

10. Ex (4/13): IH requirements capture • Use case sequence diagram • Add recipe

11. Ex (5/13): IH requirements capture • Use case sequence diagram • Add recipe – alternative flow

12. Ex (6/13): IH requirements capture • Class diagram • From the use case sequence diagrams, we can deduce a first class diagram

13. Analysis (1/6) • The goal is to find the objects, link them and make them work • Completed when the state machine for each class is described • We use scenarios to find the behavior of each object and summarize this into a state machine • In analysis we deal with the ideal world and it consist of objects only • Everything is represented by an object

14. Analysis (2/6) • After analysis, you have a complete system that works, disregarding platform, programming language, tools, etc • There is no notion of running, an object is simply alive • When objects are declared persistent, they are always there • In design we talk about storing and retrieving from the database

15. Analysis (3/6) • Getting started • Look at the use cases • What do we know now? • Ask questions • Ex: Why does the system need a certain thing (e.g. Recipes)? • Describe the static situation in class diagrams • What is always true? • Dynamic behavior is not associated with a class • Dynamic behavior is shown in the realizations of the use cases • Sequence diagrams • E.g. an active class does things on its own, this behavior has to be shown

16. Analysis (4/6) • From Requirements capture, copy the use cases but not the scenarios • In the sequence diagrams the actor is not used • We don’t care about the actor, since we are looking at the inside of the system. • As long as we receive the triggering event, we don’t care from whom. Instead we use a class named e.g. Anyone

17. Analysis (5/6) • The actors are still important when looking at interfaces to the outside • E.g. the creation of recipes is in the interface between the actor and the system • It is not a use case because it is not what the system does • The interface can be inside or outside the system. • Outside – the recipe will be created with no help from the IH • Inside – we can use information in the IH to create the recipe

18. No attributes in analysis, we do not need them They will appear in design Aggregation and inheritance is very close Whenever there is one, you can think of the other Association vs. aggregation A question of lifetime In state machines Transactions Take no time Nothing can go wrong States Takes time Do – an ongoing thing (as long as you’re in that state) Analysis (6/6)

19. Ex (7/13): IH analysis • Class diagram • Static model

20. Ex (8/13): IH analysis • Use case realization • Add recipe

21. Ex (9/13): IH analysis • Use case realization not related to use case • New data from equipment

22. Design (1/8) • Analysis is the solution and design is what needs to be done to adapt it to the real world • In design you think in the virtual world (in the computer) and the real world • The goal is to distribute what is found in analysis between these two worlds

23. Design (2/8) • Getting started • Check the static description in analysis • Class descriptions • Names for associations • Navigability • Cardinality • Make design choices • Programming language, database, middleware, etc • Address one constraint at a time • Show how the classes are distributed on different nodes • A node is e.g. one Java Virtual Machine • Described in a deployment diagram

24. Design (3/8) • An analysis class may be distributed among several design classes • An analysis class may or may not be implemented in the end. It depends on if you will treat objects uniformly or not • No need if you’ve e.g. broken the analysis interface, then you will never be able to access the objects through this interface • Can only do design of objects for which we know the behavior (see state diagrams in analysis) • Distribute the classes into packages that have well-defined interfaces to other packages • Replace all associations names with roles  names for attributes

25. Design (4/8) • In design you will find new classes • Need to be defined completely with state diagrams • The sequence diagrams from analysis will be extended and new ones created to focus in on the more detailed behavior • The design of one analysis class should not depend on the design of another analysis class • Design classes uses analysis interfaces • This may be broken for e.g. technology reasons. Ex: You don’t want to return the complete object but a representation and you specify which one in the method call • The interface of a class should not reflect its design

26. Design (5/8) • The only additional association between a design class and an analysis class is inheritance • Message vs. method • In a message you know the sender, the receiver, the message, the parameters, and if it is synchronous or asynchronous, etc. • In a method you just know the name of the method and the parameters • If you want to know the sender e.g. you have to give it explicitly as a parameter • In design, we have to decide how to implement messages

27. Design (6/8) • Don’t work directly on the analysis class • In design we are working with a particular set of choices

28. Design (7/8) • Object concept implementation diagrams • show how different concepts should be implemented (e.g. many-to-many relations, one-to-many relations, etc)

29. Impl Design (8/8) • Ex. of concepts whose implementation needs to be decided on

30. Ex (10/13): IH design • Technology choices • Using Java • Change names for classes and messages to Java standard • Remove multiple inheritance • The <<role>> stereotype in UML is close to an interface in Java

31. Ex (11/13): IH design • Deployment diagram

32. Ex (12/13): IH design • Every persistent object will have two views • One persistent – what do you need to keep? Maybe not only the attributes, but also e.g. the current state of the machine • One that lives in the software

33. Ex (13/13): IH design • Class diagram

34. Organization in Rose (1/4) • Requirements capture Use Case View • Analysis Logical View • Design Logical View • Implementation Component View

35. Organization in Rose (2/4) • Requirements capture • Diagrams that show actor relations • Diagrams that show primary/secondary use case-use case relations • Diagrams that show actor-use case relations

36. Organization in Rose (3/4) • Analysis and design • Diagram to show use case-classes relation (interesting at the end) • External classes needed to describe the system, but not in the system • Classes seen from the outside (published in a controlled unit) • Classes from outside used in the system (imported in controlled units)

37. Organization in Rose (4/4) • Script to generate package structure • A number before the package name ensures that the ordering is maintained • All associations concerning classes in a package need to be in the same package • Rose stores them where they are created • Traceability • Between use cases in requirements capture and analysis – create a diagram in the Use cases sub package in the Analysis package • Same thing for classes