Design Theory Software Engineering Fundamentals (SEF): MS.NET

1. Software Engineering Fundamentals (SEF): MS.NET

7.1 Design Theory
Software
Engineering
Fundamentals
(SEF): MS.NET

2. Contents

1 Application Workstream
2 Use Case diagrams
3 Sequence diagrams
4 Class definitions
5 Interface definitions
6 Class diagrams
7 Component diagrams
8 Component definitions
2

3. Objectives

Describe the
importance of accurate
and thorough design
documentation
Identify class, interface
and component
definitions
1 Use case diagrams
2 Sequence diagrams
3 Class diagrams
4 Create a complete class diagram
Describe the purposes
and basic notation of
the following diagrams:
3

4. Application Workstream

Go to the Accenture Delivery Methods, local directory or:
https://methodology.accenture.com/adm/
4

5. Analyze Phase to Design Phase

Analyze Phase
Design Phase
5

6. Design to Build Phase Transition

6

7. What is a use case?

Use cases describe:
• The way that actors interact with the application
• The resulting behavior of the application
Use Case
Event
Actor
An actor interacts
with the system. An
actor may be a user
or another system.
A use case is a sequence of
actions performed by the
system. A use case yields an
observable result that is of
value to a particular actor.
7

8. Use Case Diagram

Use Case diagrams are typically used to communicate the
high-level functions of the system and the system's scope.
It specifies what the system does and not how it does it.
They are represented through use cases, actors, and their
relationships.
• A use case, depicted as an ellipse, illustrates a system
functionality.
• An actor, depicted as a stick person, represents the
people or other systems (like an organization) that
interact with the system.
• Relationships between actors and use cases are shown
via solid lines. Inheritance between actors and between
use cases are shown by a close-headed arrow to the
parent. <<include>> and <<extend>> between use cases
are shown via open-headed arrows.
8

9. Sequence Diagram

Sequence diagrams are used to show
how objects interact with one another
and emphasize the order of the
messages over time.
To draw a sequence diagram:
• Identify the objects needed in the
model and draw them across the top.
• If an object sends a message to
another object, draw a solid arrow
pointing to the receiving object; place
the name of the message above the
line.
• Indicate the return value by a dotted
arrow pointing back to the originating
object; label the return value above the
dotted line.
9

10. Class Definitions

Name: Patron
• Create a descriptive name for the class according to the following points:
– Use a name meaningful in the problem domain. Use the terms defined in the glossary as much
as possible.
– Make the name a noun or a noun phrase.
– Use a text string as the name. It can contain several words. A good naming convention is to
concatenate the words together and capitalize the first letter in every word.
Description
• Briefly describe the class. A single paragraph of text should suffice.
Parent Class: Person
• Name the superclass this class inherits from.
10

11. Class Definitions (Contd.)

Responsibilities
• Describe class responsibilities in the Requirements gathering/Analysis stage.
Attributes
• Create the class attributes in the Analysis stage and refine the specifications in the Design and
Build stages.
11

12. Class Definitions (Contd.)

Operations
• Create the class operations in the Design stage and refine the specifications in the Build stage.
Additional Information
• Document any additional information about this class (e.g., collaborations with other classes,
external interfaces, implementation considerations, etc.)
12

13. Interface Definitions

Interface Definition
Name:IPatron
• Name of the interface. The prefix “I” indicates that its an interface.
Description
• IPatron is an interface which is implemented by the business class Patron and contains the
operations related to a patron of a library management system.
Parent Interface: n/a
• Name of the parent interface which this interface implements.
Additional Information
• Document any additional information about this interface like the type of classes which should
implement this interface, the type of layer it interfaces etc.
13

14. Class Diagram

Class diagrams show the different entities
(classes), how they relate to each other, and their
attributes and operations.
Class diagrams are used for a wide variety of
purposes, including both conceptual or domain
modeling, and detailed design modeling.
Some of the basic notation include:
• Class. A rectangle with compartments showing the
name, attributes, and operations of the class.
• Association. Line showing interaction and multiplicity
between classes.
• Inheritance. Models “is a” and “is like” relationships
and shown by a close-headed arrow to the parent.
• Composition. Models “is part of” relationships and
shown by an arrow with a blocked diamond to the
whole.
14

15. Structural Modeling: Core Elements

Construct
class
interface
component
node
constraint
Description
A description of a set of objects
that share the same attributes,
operations, methods,
relationships and semantics
A named set of operations that
characterize the behavior of an
element
A physical, replaceable part of a
system that packages
implementation and provide the
realization of a set of interfaces
A run-time physical object that
represents a computational
resource
A semantic condition or
restriction
Syntax
«interface»
{constraint}
15

16. Structural Modeling: Core Relationships

Construct
Description
association
A relationship between two or more
classifiers that involves connections among
their instances
aggregation/
composition
A special form of association that specifies a
whole-part relationship between the
aggregate (whole) and the component part
generalization
A taxonomic relationship between a more
general and a more specific element
dependency
A relationship between two modeling
elements, in which a change to one modeling
element (the independent element) will affect
the other modeling element (the dependent
element)
realization
A relationship between a specification and its
implementation
Syntax
16

17. Component Definitions

Component Definition
Name
PatronManager
Description
This component supports patron information maintenance: creates/updates patron records,
authorizes patron for new loans, etc.
Interfaces
Name
MaintainPatronRecord
AuthorizeLoan
Description
Provides the services needed for patron information maintenance
Validates that the patron can get a new book loan
Sub-components
Name
Patron
PrivatePatron
ContactPatron
Type
Class
Class
Class
Description
Represents generic patron information
Represents information specific to an individual user
Represents information specific to a contact person who
uses library services on behalf of an organization
17

18. Component Diagram

Component diagrams are used to model the
relationships between software components in
a system, i.e., a physical view of the system.
They are graphs of components connected by
dependencies and interfaces
• A component represents a modular, deployable,
and replaceable part of a system
• A dependency is shown as a dashed arrow from
the dependent component
• A component may implement an interface, and
the interface can be shown as a lollipop joined to
the component by a dashed arrow; required
interfaces are shown via the socket symbol
18

19. Key Points

Use case diagrams are typically used to communicate the high-level
functions of the system and the system's scope.
Use cases describe:
• The way that actors interact with the application
• The resulting behavior of the application
Sequence diagrams are used to show how objects interact with one another
and emphasize the order of the messages over time.
Class, interface and component definitions describe the details of a class,
interface or component, respectively.
Class diagrams show the different entities (classes), how they relate to each
other, and their attributes and operations.
Component diagrams are used to model the relationships between software
components in a system, i.e., a physical view of the system.
19

20. Agile: User Story

Template:
As a <type of user>, I want <some goal> so that <some reason>.
Reasoning:
- Focus on People needs
- Easy to change
- Easy to understand by developers
20

21. Questions and Comments

What questions or comments
do you have?
2