HFOOAD Chapter 7 Architecture

Chaos

2

3

If we just had a way to tie all of this information together we might be able to figure out what to do first.

You need an architecture!

Software architecture is…

a.  The structure of your application or system

b.  The most important (key) components of your system

c.  The relationships between the parts of your system

d.  The reason why you chose a particular component or representation of the relationships between your components

e.  The design patterns you apply

4

Your answer is?

Architecture is…

a.  The structure of your application or system b.  The most important (key) components of your system c.  The relationships between the parts of your system d.  The reason why you chose a particular component or

representation of the relationships between your components

e.  The design patterns you apply f.  All of the above!

5

6

Software architecture is the organizational structure of a system, including its

decomposition into parts, their connectivity, interaction mechanisms, and the guiding

principles and decisions that you use in the design of a system.

7

So now we need to document all of the details? This will take too long. Can we just start coding? A lot of people think that they

have to get all of the details. You just want to “flesh out” the big things.

8

The architecture is the blueprints for your system

What are software blueprints

‣  Requirements, especially use cases ‣  UML diagrams ‣  Class

‣  Package / component

‣  Sequence

‣  Others

‣  Interfaces ‣  Key classes with methods ‣  Prototypes ‣  …

9

I still don’t understand what corresponds to the blueprints for software apps.

What must the system do?

10

One prioritization

11

12

I’m sorry but that’s not how I prioritize the features and I’m paying for this work!

Why not just get the customer to prioritize them to start with?

Three Qs of architecture

1.  Is it part of the essence of the system? ‣  If you can’t build the system without it, it’s essential

2.  What does it really mean? ‣  Do you really understand this feature

3.  How can I implement it? ‣  Lack of knowledge ‣  New or non-existent technology

13

Evolutionary design

‣  Designs evolve but not from the simple to the difficult

‣  Evolutionary design means that we can add to it as we go ‣  Incremental design

‣  Flexible design

‣  Iterative, incremental development

14

Why not start with the easy things and let the design evolve. Isn’t that an Agile principle?

Architecture reduces risk

15

Cha

nce

of fa

ilure

Project duration

Easy first

Focus on architectural significance

Our prioritization rationale

16

Sharpening our focus

17

The board challenge

18

Scenarios

‣  A scenario can be one path through a use case ‣  The use case consists of many,

possibly infinite, scenarios

‣  A scenario can be a part of a use case or any meaningful sequence of actions

‣  Scenarios help us think about how the system works for one particular situation

19

Isn’t the board challenge a scenario?

Board challenge scenario

20

Create message

Code for the board challenge (1)

21

22

Code for the board challenge (2)

Scenario scramble

23

One possible scenario

24

Structure and relationships

25

Stop or go on?

Can we move on now? I know what we have to do for the board? This is too simple.

Wait a minute. What about saving the board, loading saved games, and so on. We can’t move on yet.

Focus on the goals Reasons to move on

‣  We know how to create a board

‣  We have described the interface for getting a particular tile and adding units to a particular tile on the board

‣  We have an idea about how the units, tiles, and board are related

Reasons to keep working on the board ‣  It’s not complete

‣  We haven’t figured out how to implement persistence so we can save and reload boards

‣  We haven’t established the coordinate system

27

Game specific units

We can probably work on the units next. I think I’m getting the hang of this evolving design.

What the heck does this mean?

28

Talk to the experts

29

30

Each game based on the framework has different types of units, with different attributes and capabilities. So we need to be able to have properties for a unit that are different for each game, and support multiple data types for those properties.

What does “game-specific units” mean?

Commonality analysis revisited

31

1

2

3

4

Some possible properties

32

Unit commonality analysis

33

No commonality

34

Draw upon your experience

35

Where have you had to solve a problem similar to this before?

So, everything can be unique and maybe even different types. Haven’t we solved a similar problem?

Handle the properties in a common way

36

We’ve covered the 2nd key feature

37

Three-step process

38

We’ve gone through this a couple of times now. Can you identify a three-step process that will help you move forward with the third key feature: “coordinate movements”?

1

2

3

39

Step 1: Ask the customer

40

Step 2: commonality analysis

41

Step 3: how to implement

42

There is no commonality!

Review: Reducing risk

43

44

And you’ve got an (executable) architecture!

Additions to your toolbox

45

But what if…

46

Two common turn descriptions Turn type 1

‣  Player A moves as many units as desired. Each move is performed as in steps 2-4 of turn type 1.

‣  Player A brings in reinforcements

‣  Player B goes through steps 1-2

‣  The turn counter is advanced by one

47

Turn type 2

‣  Player A moves one unit

‣  The game ensures that the move is valid

‣  The move is made

‣  The results of the move are calculated and the board is modified accordingly

‣  Player B goes through steps 1-4

‣  The turn counter is advanced by one

Modify your design

48

Hint!