System Development Techniques Individual Assignment

System Development Techniques

Diploma in Information Technology

Lesson 15

Learning outcomes After studying this chapter and the recommended reading, you should be able to:

• Explain use case realisation with sequence diagrams

• Describe the MVC design pattern

Use Case Realization

Use Case Realization with Sequence Diagrams

• Design process for sequence diagrams is the same as communication diagrams. – Starts with SSD and first-cut design class diagram.

• Other models, such as a use case description and activity diagram, are also helpful.

– SSD only has two lifelines—one for the actor and one for the system.

– Starting with the SSD, each input message is taken, one at a time, and extended to all of the internal classes so that the desired result is obtained. Any data to be returned is identified and added.

Use Case Realization with Sequence Diagrams

• Below is the sequence diagram solution of the Create customer account use case. – Developed using the same three steps that were used to extend

communication diagram messages.

• Has the same set of messages, but displayed differently. • Primary benefit of the sequence diagram is the ability to lay

out the messages from top to bottom to emphasize the sequence of firing.

Use Case Realization with Sequence Diagrams

Sequence diagram from Create customer account use case

Communication diagram from Create customer account use case

Use Case Realization with Sequence Diagrams

• Sequence Diagram – The actor is an external role, in this case, a Clerk. – The boxes are instantiated objects from the corresponding

classes. Object notation is used. E.g. aC:Customer.

Use Case Realization with Sequence Diagrams

• Sequence Diagram – Below each actor and object is a lifeline, which is used as

an indicator of the life of the object.

Use Case Realization with Sequence Diagrams

• Sequence Diagram – Attached to locations of each lifeline are vertical boxes representing

activation lifelines. • time period when a method is executing.

Use Case Realization with Sequence Diagrams

• Sequence Diagram – Messages are attached to the lifeline either as a source

point or a destination point.

Use Case Realization with Sequence Diagrams

• Sequence Diagram – Two ways to indicate data being returned,

• by a return assignment with the “:=” operator, or • as a return message using a dashed arrow.

Use Case Realization with Sequence Diagrams

• When a message is sent from an originating object to a destination object, in programming terms, it means that the originating object is invoking a method on the destination object.

• Thus, by defining the messages to various internal objects, we are actually identifying the methods of that object.

• Once a use case is realized with this detailed design process, the set of classes and required methods can be extracted so programming can be completed.

Use Case Realization with Sequence Diagrams

• Good design principles – Use case controller provides the link between the internal

objects and the external environment. – Responsibilities assigned to :CustomerHandler are to catch

incoming messages, distribute them to the correct internal domain objects, and return the required information to the external environment.

Use Case Realization with Sequence Diagrams

• Good design principles – The responsibility assigned to :Customer is to be in charge

of creating itself and to control the other required updates to subordinate objects.

– The :Address and :Account objects create themselves. – The assignment of responsibilities and corresponding

messages conforms to good design principles. – Other issues will need to be addressed as the design

expands to include three layers.

Developing a Multilayer Design

• So far in the development of the sequence diagram, we have focused only on the classes in the problem domain layer.

• In many instances, this may be sufficient documentation to program the solution—either by yourself or with another programmer.

• Once you have a solid design for the problem domain classes, adding the view layer and the data access layer is a straightforward process.

Developing a Multilayer Design

• Add customer account use case with view layer added view layer

Developing a Multilayer Design

• Designing the View Layer – Add an object for each input form or screen.

Developing a Multilayer Design

• Designing the View Layer – Add the appropriate messages from the Actor to the input

«view» objects.

Developing a Multilayer Design

• Designing the View Layer – Messages are added for

• the :CustWindow to open the :AddrWindow, • the :AddrWindow to open the :AcctWindow.

Developing a Multilayer Design

• Designing the Data Access Layer – Purpose of data access layer is Principle of separation of

responsibilities. – For complex systems, designers create three-layer designs,

including classes whose sole responsibility is executing database SQL statements, getting the results of the query, and providing the information to the domain layer.

– Multilayer design was used to support multitier networks in which the database server was on one machine, the business logic was on another server, and the user interface was on several desktop client machines. This way of designing systems creates more robust and more flexible systems.

Developing a Multilayer Design

• Designing the Data Access Layer – When an object is updated, it also needs to be written to

the database. – Send a message to the data access object together with

the required parameters. – The data access method can pull out the attributes, format

an SQL insert or update statement, and write it to the database.

Developing a Multilayer Design

• Designing the Data Access Layer

Data Access Layer

Developing a Multilayer Design

• Designing the Data Access Layer – Addition three data access objects and have the newly

created objects send messages to write themselves out to the database.

– The diagram is organized with • the view layer on the left, • the problem domain layer in the middle, and • the data access layer on the right.

Packaging the Design Classes

• Package diagram – A high-level diagram to associate classes of related groups. – Separating or grouping objects based on

• certain characteristics (e.g. MVC) or • in a distributed environment (e.g. client or server)

– Shows dependency relationships between each layers. – This information can be captured by showing each layer as

a separate package.

Packaging the Design Classes

• Package diagram – The classes are placed

inside the appropriate package based on the layer to which they belong.

Packaging the Design Classes

• Dependency relationship. – The arrow’s tail is connected to the package that is dependent, – Arrowhead is connected to the independent package. – To read a dependency relationship, read it in the direction of

the arrow. – If one element changes (the independent element), the other

(dependent) element might also have to be changed. • if a change is done in the independent element, need to

check how the change affect the dependent element. – Dependency relationships can be between packages or

between classes within packages.

Summary

• Design process for sequence diagrams is the same as communication diagrams.

• Primary benefit of the sequence diagram is the ability to lay out the messages from top to bottom to emphasize the sequence of firing.

• MVC is a good design pattern to support large and complex system.

Summary

• Package diagram is a high-level diagram to associate classes of related groups.

• It separates or grouping objects based on certain characteristics (e.g. MVC) or in a distributed environment (e.g. client or server)

• It shows dependency relationships between each layers. • If one element changes (the independent element), the other

(dependent) element might also have to be changed. • If a change is done in the independent element, need to

check how the change affect the dependent element.

Read

Textbook:

• Satzinger, Robert & Stephen Chapter 13