System Development Techniques Individual Assignment

System Development Techniques

Diploma in Information Technology

Lesson 13

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

• Discuss on the bridging from analysis to implementation

• Explain object-oriented architectural design • Explain the object-oriented detailed design

Overview of Object-Oriented Programs

• An object-oriented program – consists of sets of computing objects. – each object has data and program logic encapsulated

within itself. – define the structure of the program logic and data fields by

defining a class. – the class definition describes the structure or a template

of what an executing object looks like. – from class we can instantiate object. – instantiation of the class—making an instance (an object)

based on the template provided by the class definition.

Overview of Object-Oriented Programs

• An object-oriented program – consists of a set of these instantiated objects that

cooperate to accomplish a result. – objects work together by sending each other messages

(calling methods) and working in concert to support the functions of the main program.

Overview of Object-Oriented Programs

• An object-oriented program – Think of how people in a company from different department works

together to run the company. • Department -> layer

(e.g. view, controller, model) • People -> object • People communicate with each other ->

object calling another object method.

Overview of Object-Oriented Programs

• An object-oriented program example • A window object that displays a

form • User enters a student ID and other

information (message 1). • After the student ID is entered, the

Window object sends a message (message 2) to the Student class to tell it to create a new Student object (instance) in the program.

Overview of Object-Oriented Programs

• An object-oriented program example • The new Student object knows that it needs

more data for some of its attributes based on internal logic in the student class,

• The Student object send a message to a Database Access object asking for data from the database (message 3).

• Once the Student object is completely instantiated with all the required data, the Student object sends the information back to the Window object to display it on the screen.

Overview of Object-Oriented Programs

• An object-oriented program example • The user then enters the updates to her

personal information (message 4), and another sequence of messages is sent to update the Student object in the program, which forwards information to the Database Access object and writes it to the database.

Overview of Object-Oriented Programs

• An object-oriented program – consists of many objects. – each object, consists of program logic exists in small segments called

methods. – methods are “called” or invoked through messages

• Object calling methods of another object. – there are three type of objects,

• “Three-layer architecture,” – Window object (view layer), – Student object (domain or business logic layer), – Database Access object (data layer).

Analysis Models to Design Models

• To write a computer program, a programmer needs to know – what the classes are, and – what the methods are in those classes.

• The previous example is a single use case – Update student information.

• A programmer will work on one use case at a time. – select a use case and code the appropriate methods in the required

classes to carry out that use case.

• For programmer to perform the above task, the design models must support that activity.

Analysis Models to Design Models

• For each use case, the design models must provide the information required to – identify the classes – document the flow of execution (for coding of methods)

• Diagram below shows the model building process flows from analysis to design to implementation

Introduction to the Design Models

• Design class diagram – Primary model used to document the classes and the methods. – Extension of the domain model class diagram that was developed

during analysis activities and requirements definition. – The diagram shows a Student class both as the domain class and as

the design class.

Introduction to the Design Models

• To document the flow of execution of a particular use case, use – sequence diagram, – a communication diagram, – or CRC (class responsibility collaboration) cards.

• do not need to use all three for any given use case. • Sequence diagrams and communication diagrams are

standard UML interaction diagrams. • CRC cards are not standard UML, but are very popular for

designing simple system

Introduction to the Design Models Sequence Diagram

• System sequence diagrams (SSD). – In analysis phase – Only two actors, the external actor and the system.

• Sequence diagram – expands the system object to identify the internal

interacting objects.

Introduction to the Design Models Sequence Diagram

• Sequence diagram – a simple sequence diagram.

– System object is no longer included,

Introduction to the Design Models Communication Diagram

• A communication diagram – Provides basically the same information as sequence

diagram, but in different formats.

Introduction to the Design Models CRC

• Class Responsibility Collaboration (CRC) – Provides a straightforward approach for detailed object-

oriented design, especially for simple use cases. – include a set of cards, with each card representing a class. – each card identifies • the class, • its responsibilities (i.e., its methods), and • the other classes with which it collaborates.

Introduction to the Design Models CRC

• Class Responsibility Collaboration (CRC) – Diagram shows both front and back sides of one single CRC card. – The card represents a class. – The list on the front left is the “responsibilities.” – The list on the front right is the other classes with which this class

must “collaborate.” – The list on the back is the attributes.

Steps of Object-Oriented Design

• Object-oriented design – three separate layers: user interface, problem domain, and

database access layers. – process that identifies and describes the classes within

each layer . – defines the messages that are used to invoke the methods

of the involved classes. • Object-oriented design is an analytical, rigorous, and detailed

process. Don’t be discouraged if it takes several tries before you feel comfortable with this skill.

Steps of Object-Oriented Design

• Simple use cases – at times it is easier just to code the use case, rather than develop a

formal use case design.

• If a model or diagram will assist in that objective, then it should be created.

• If it does not contribute directly to the end result, then time should not be spent on it.

• However, should not just skip modelling with the assumption that a model is a distraction rather than a necessary step in creating a solid design for the software.

Steps of Object-Oriented Design

• Steps required in object-oriented design

Steps of Object-Oriented Design

• In any of the three techniques for modelling, the objective is to identify and define the methods that are required in each class.

• The final design class diagram documents these required methods.

• A package diagram is added to divide the classes into components or subsystems that can be implemented as a unit.

Design Classes and the Design Class Diagram

• Design class diagram – contains the final definition of each class in the final

object-oriented software system. – primary source of information for this diagram is the

domain model. • domain model

– shows a set of problem domain classes and their associations. – serves as the basis for database design, and – for the software classes as defined in the design class

diagram. – done in analysis stage, generally don’t worry much about the

details of the attributes

Design Classes and the Design Class Diagram

• Design class diagram – In design stage, enhance the domain model

• attributes of a class must be declared as public or private and • attribute must also be defined by its type, (e.g. String or numeric) • define the methods and parameters that are passed to the

methods and the return values from methods.

Design Classes and the Design Class Diagram

• Design class diagram – As developers build the design class diagrams, they add many more

classes that were not originally defined in the domain model. • Refer to previous Update student information, the Input window

objects and Database access objects are examples of additional classes that are not problem domain classes.

• The classes in a system can be partitioned into distinct categories, such as user-interface classes or data access classes. (stereotyping)

• At times, designers may also develop distinct class diagrams by subsystem.

Design Class Stereotypes

• Stereotype – a way to categorize a model element as a certain type. – extends the basic definition of a model element by

indicating that it has some special characteristic to highlight.

– notation for a stereotype : «control». – four types of standard stereotypes: • an entity class, • a boundary or view class, • a controller class, and • a data access class.

Design Class Stereotypes

• Stereotype

Design Class Stereotypes

• Entity class – design stereotype for a problem domain class. – typically describes something users deal with when doing

their work. – Objects of entity classes usually need to be remembered – also referred to as persistent classes.

• The way to make data persistent is to write it to a file or database so that it is saved and can be retrieved at a later execution of the software.

Design Class Stereotypes

• Boundary or view class – is specifically designed to live on the system’s automation

boundary. – In a desktop system, these classes would be the windows

classes or Web pages and all the other classes associated with the user interface.

– could also be a system interface between a company’s system and an external system.

Design Class Stereotypes

• Controller class – mediates between the boundary classes and the entity

classes. – responsibility is to catch the messages from the boundary

class objects and send them to the correct entity class objects.

– acts as a kind of switchboard between the boundary or view layer and the domain layer.

Design Class Stereotypes

• Data access class – is used to retrieve data from and send data to a database. – also called a database access class. – a separate layer of classes to access the database is often

included in the design. – separate the insert database access logic, including SQL

statements, from the entity class.

Design Class Notation

• The format that analysts use to define each attribute includes the following: – Visibility – Attribute-name – Data-type-expression (return datatype) – Initial-value – Property

Design Class Notation

• Visibility – denotes whether other objects can directly access

the attribute. • + plus sign, public • - minus sign, private • # pound sign, protected

Design Class Notation

• Data-type-expression – Return datatype – such as character, string, integer, number, currency, or date

• Initial-value, if applicable • Property (within curly braces), such as {key}, if

applicable

Design Class Notation

• Method signature – shows all the information needed to invoke (or call) the

method. – shows the format of the message that must be sent, which

consists of these attributes: • Method visibility • Method-name • Method-parameter-list (incoming arguments) • Return-type-expression (the type of the return parameter from

the method) – Note some programming language (e.g. Java) does not include Return-

type-expression as method signature

Design Class Notation

Design Class Notation

• Domain model – attribute list contains all attributes discovered during

analysis activities.

• Class diagram – includes more information on attribute types, initial

values, and properties. – include a stereotype for clarification.

• UML is meant to be a general object-oriented notation and not specific to any one language. Thus, the notation won’t be the same as programming method notation.

Design Class Notation

• Class-level method – Static method in Java – Refer to Student class, the

method called findAboveHours (int hours): studentArray, which is denoted with an underline. • Class-level/Static method belongs

to the Class. • Instant method (non underline)

belongs to each object.

Design Class Notation

• Generalization/specialization. – inheritance

• Each of the three subclasses inherits all the attributes and methods of the parent Sale class.

• Each subclass has a saleID, a saleDate, and so forth.

• Each subclass also has additional attributes that are unique to its own specific class.

Design Class Notation

• class-level (static) attributes • attribute that is

underlined,

Design Class Notation

• Abstract class • Class name that is italic.

(e.g. Sale) • a class that can never be

instantiated. • To be inherited by other

class. • Provides a central holding

place for all the attributes and methods that each of the three subclasses will need

Developing the First-Cut Design Class Diagram

• Developed by extending the domain model class diagram.

• Requires two steps: 1. add type and initial value

information to the attributes 2. add navigation visibility

arrows.

Partial Sales subsystem domain model class diagram

Developing the First-Cut Design Class Diagram

• Elaboration of Attributes – fairly straightforward process. – type information is determined by the designer, based on

his or her expertise. – all attributes are kept public or private or protected. – add a new compartment to each class for the addition of

method signatures.

Developing the First-Cut Design Class Diagram

• Navigation Visibility – ability of one object to interact with and send messages to

another object. – Diagram shows “one-way” navigation visibility between

the Customer class and the Sale class.

Developing the First-Cut Design Class Diagram

• Navigation Visibility – “one-way” because Customer can interact with Sale, but

Sale does not have a direct reference back to Customer. – navigation arrow indicates that a Sale object must be

visible to the Customer object.

Developing the First-Cut Design Class Diagram

• Navigation Visibility – Variable mySale in the Customer class refers to a Sale

instance. – The mySale attribute is included in the example to provide

a way to actually implement it. (reference or pointer) – think of it as having a Sale object embedded within the

Customer object.

Developing the First-Cut Design Class Diagram

• Navigation Visibility – database implementation

• do the reverse. • put a foreign key of the Customer in the Sale data record to

capture the one-to-many relationship. (One customer has many sales.)

Developing the First-Cut Design Class Diagram

• Navigation Visibility – Which classes need to have references to or be able to

access which other classes? – General guidelines: • One-to-many associations

– indicate a superior/subordinate relationship are usually navigated from the superior to the subordinate

– for example, from Sale to SaleItem. • Mandatory associations,

– objects in one class can’t exist without objects of another class, are usually navigated from the independent class to the dependent class—for example, from Customer to Sale.

Developing the First-Cut Design Class Diagram

• Navigation Visibility – General guidelines: • When an object needs information from another

object, a navigation arrow might be required, pointing either to the object itself or to its parent in a hierarchy. • Navigation visibility arrows may be bidirectional—for

example, a Sale object might need to send a message to its Customer object as well as the reverse.

Developing the First-Cut Design Class Diagram

• Controller class: – The very first step to do when creating the first-cut design

class diagram is to add a controller class. – is a switchboard between the input screens and the

programming logic classes, i.e. the domain classes, for a particular use case.

– always create a controller class for each use case, and place it between the user-interface classes and the problem domain classes.

– More details in next lesson.

• First cut class diagram

Developing the First-Cut Design Class Diagram

• First-cut Design Class Diagram – add a controller class • includes SaleHandler as the controller class. • a controller class, or use case controller, is a utility class

that helps in the processing of a use case. • has navigation visibility at the top of the visibility

hierarchy and starts the use case by messaging a customer.

Developing the First-Cut Design Class Diagram

• First-cut Design Class Diagram – elaborate attributes • add type information and visibility

– identify navigation visibility. • first identify which classes may be involved and then

determine the classes that require navigation visibility to other classes.

Developing the First-Cut Design Class Diagram

• First-cut Design Class Diagram – identify navigation visibility. • price information is in the PromoOffering class • description information is in the ProductItem class. • In most instances, it is unnecessary to put the

navigation visibility reference attribute in the class. (this information is implied by the arrow) • the mySale attribute is redundant to the information

provided by the arrow. So, even though it was shown in the previous diagram to emphasize the concept of navigation visibility, it is left off in the previous and subsequent figures.

Designing with CRC Cards

• Class Responsibility Collaboration (CRC) – brainstorming and design technique for object-

oriented developers. – use this technique during design to help identify

responsibilities of the class and the sets of classes that collaborate for a particular use case.

Designing with CRC Cards

• CRD Card – card with lines that partition it into three areas:

class name, responsibility, and collaboration classes.

Designing with CRC Cards

• Process of developing a CRC model – Before the design session, each team member

should have • domain model class diagram • list of use cases • Other documents if available

– activity diagrams, system sequence diagrams, and use case descriptions,

• stack of blank CRC-formatted index cards.

Designing with CRC Cards

• Process of developing a CRC model – For each use case repeat these steps: 1. Select a use case. • The first card to include should be a use case

controller card.

Designing with CRC Cards

2. Identify the first problem domain class that has responsibility for this use case. • This object will receive the first message from the use

case controller. • Using the domain model that was developed during

analysis, select one class to take responsibility. • Focus only on the problem domain classes. • On the left side of the card, write the object’s

responsibility. • For example, a Customer object may take responsibility

to make a new sale, so one responsibility may be Create phone sale.

Designing with CRC Cards

3. Identify other classes that must collaborate with the primary class to complete the use case. • Do the above by identify the classes that have required

information or that need to be updated in this use case. • Then go to the appropriate CRC card for that class and

write its responsibilities and attributes on the cards.

Designing with CRC Cards

4. Include the user-interface classes. • Optional but helpful step. • If some preliminary work has been done on the user-

interface requirements, it could be effective to add CRC cards for all user-interface window classes that are required for the use case.

• By including user-interface classes, all the input and output forms can be included in the design, making it much more complete.

Designing with CRC Cards

5. Add any other required utility classes that are needed to the solution. • For example, for a three-layer design, data access

classes will be part of the solution. • Usually, each persistent domain class will have a data

access class to read and write to the database.

Designing with CRC Cards

• At the end of the process, we have a small set of CRC cards that collaborate to support the use case.

• The process can be enhanced by – arranging the CRC cards on the table in the order

they are executed or called. – That is the calling order can be determined at this

time. (for drawing of sequence diagram later)

Designing with CRC Cards

Create customer account Use Case

Designing with CRC Cards

Create customer account Use Case

Fundamental Principles for Good Design

• Object responsibility – Each object should be responsible for carrying out

a part of the system processing. – Responsibilities are categorized in two major

areas: • knowing

– what is an object expected to know? • doing

– what is an object expected to do?

Fundamental Principles for Good Design

• Object responsibility – Knowing • object’s responsibilities for knowing about

– its own data – how to maintain the information in those attributes. – where to go to get information when required. – navigation visibility – knowing about other classes with which it must collaborate to carry

out use cases.

Fundamental Principles for Good Design

• Object responsibility – Doing • all the activities an object performs to complete a use

case. • activities include

• receiving and processing messages. • instantiate, or create, new objects that may be required for

completion of a use case. • Classes must collaborate to carry out a use case, and some

classes are responsible for coordinating the collaboration.

Fundamental Principles for Good Design

• Separation of responsibilities, – aka separation of concerns, – a design principle that is applied to a group of

classes rather than to each class individually. – basic idea is to segregate classes into packages or

groupings based on a primary focus of processing responsibility.

Fundamental Principles for Good Design

• Separation of responsibilities – fundamental principle behind multilayer design. – multilayer design

• user-interface classes, business logic classes, and data access classes.

• Each layer has a particular focus or area of responsibility. – Classes that share the same focus or concern are grouped

together in a layer. – This design principle allows flexibility in system

deployment because different layers, i.e., a grouping of classes, can be located on different computers or at different locations.

Fundamental Principles for Good Design

• Protection from variations (change) – parts of a system that are unlikely to change should be

segregated (or protected) from those that will change. – try to isolate the parts that will change from those that are

more stable. – Use multilayer design pattern. • Decouple the user-interface logic from the business

logic. • the user interface can be rewritten without affecting

the business logic. – In other words, the business logic—being more stable—is

protected from variations in the user interface.

Fundamental Principles for Good Design

• Indirection – is the principle of separating two classes or other system

components by placing an intermediate class between them to serve as a link.

– Don’t send a direct message from A to B. Let A send the message to C and then let C forward it to B.

– Implemented using a Use case controller. • The controller is a separate class that receives all the inputs and

directs it to the appropriate domain classes.

Fundamental Principles for Good Design

• Coupling – a qualitative measure of how closely the classes in a design

class diagram are linked. – A simple way to think about coupling is by the number of

association relationships and whole/part relationships on the design class diagram.

– Navigation visibility, • measures what a class can link to and access.

– Low coupling is usually better for a system than high coupling.

Fundamental Principles for Good Design

• Cohesion – the consistency of the functions within a single class and – is a qualitative measure of its focus or unity of purpose. – classes need to be highly cohesive to be well designed. – That is one class only do one thing (and one thing good) – Classes with low cohesion have several negative effects.

• hard to maintain because they perform many different functions, • tend to be overly sensitive to changes within the system (ripple

effects). • uually difficult to understand, their functions are intertwined and

their logic is complex.

Summary

• Design class diagram – Primary model used to document the classes and the methods. – Extension of the domain model class diagram that was developed

during analysis activities and requirements definition.

• To document the flow of execution of a particular use case, use – sequence diagram, – a communication diagram, – or CRC (class responsibility collaboration) cards.

Summary

• Class Responsibility Collaboration (CRC) – brainstorming and design technique for object-oriented

developers. – use this technique during design to help identify

responsibilities of the class and the sets of classes that collaborate for a particular use case.

• Fundamental Principles for Good Design are: – Object responsibility, Separation of responsibilities,

Protection from variations (change), Indirection, Low Coupling and high Cohesion.

Read

Textbook:

• Satzinger, Robert & Stephen Chapter 12