Object Oriented Software Engineering

Part-A (2MARKS):
UNIT I INTRODUCTION
1. Wat i! Software Engineering"
Software engineering is a #ode$ing activity. Software engineers deal with complexity
through modeling.
Software engineering is a %rob$e#-!o$&ing activity. Models are used to search for an
acceptable solution.
Software engineering is a 'now$edge ac()i!ition activity. It is a single piece of
additional data can invalidate complete models.
Software engineering is a rationa$e-dri&en activity. Rationale information represented as
a set of issue models enables us to understand the implication of proposed change whwn
revisiting a decision.
2. Wat i! #ode$ing"
Modeling is a means of dealing with complexity. Modeling means constructing an
abstraction of a system that focuses on interesting aspects and ignores irrelevant details.
*. +i!t te !te%! of %rob$e# !o$&ing.
The five steps are for#)$ating te %rob$e#, ana$,-e te %rob$e#. !earc for
!o$)tion!, decide on te a%%ro%riate !o$)tion and !%ecif, te !o$)tion.
/. W, 'now$edge ac()i!ition i! a non $inear %roce!!" E0%$ain.
Knowledge acuisition is a non linear process because of the addition of a new piece of
information may invalidate all the !nowledge we have acuired for the understanding of
a system. "ven if we had already documented this understanding in documents and code,
we must be mentally prepared to start from scratch.
1. 2efine Rationa$e.
# design rationale is the explicit listing of decisions made during a design process , and
the reasons why those decisions were made when designing a system or artifact. Its
primary goal is to support designers by providing a means to record and communicate the
argumentation and reasoning behind the design process.
3. 4o#%are %artici%ant and ro$e.
The client orders and pays for the system. The developers construct the system. The
pro$ect manager plans % budgets the pro$ect % co&ordinates the developers and client.
The end users are supported by the system. The persons involved in the pro$ect are
referred to as %artici%ant!. The set of responsibilities in the pro$ect or a system as a ro$e.
5. Wat i! wor' %rod)ct" +i!t it t,%e!.
# wor! product is an artifact that is produced during the development, such as a
document or a piece of software for other developers or for the client.
The types of wor! product are 'eliverable % Internal wor! product.
6. 2efine acti&it,. ta!' and re!o)rce!.
#n acti&it, is a set of tas!s that is performed towards a specific purpose.
# ta!' represents an atomic unit of wor! that can be managed.
Resources are assets that are used to accomplish wor!.
7. 2i!ting)i! f)nctiona$ and non f)nctiona$ re()ire#ent!
The f)nctiona$ re()ire#ent! specify what the product must do.
They relate to the actions that the product must carry out in order to satisfy the
fundamental reasons for its existence.
8onf)nctiona$ Re()ire#ent is a constraint on the operation of the system that is not
related directly to a function of the system.
The non&functional reuirements add functionality to the product && it ta!es some amount
of pressing to ma!e a product easy to use, or secure, or interactive.
19. 2i!ting)i! #etod and #etodo$ogie!.
# #etod is a repeatable techniue that specifies the steps involved in solving a specific
problem. E0a#%$e: # recipe is a method for coo!ing a specific dish.
# methodology is a collection of methods for solving a class of problems and specifies
how and when each method should be used.
11. En$i!t te !oftware engineering de&e$o%#ent acti&itie!.
The software engineering development activities are Reuirements "licitation, #nalysis,
System design, (b$ect design, Implementation % Testing.
12. Wat i! te i#%ortance of te!ting"
Testing is the systematic attempt to find faults in a planned way in the implemented
software.
Testing is the process of demonstrating that faults are not present.
Testing try to detect faults in the system that is, differences between the reality of the
system and the reuirements.
1*. W, i! ana$,!i! re()ired for a diffic)$t ta!'"
#nalysis is reuired for a difficult tas! to produce a model of the system that is correct,
consistent, and unambiguous. 'uring this activity, developers discover ambiguities and
inconsistencies in the use case model that they resolve with the client. The result of
analysis is a system model annotated with attributes, operations and associations.
1/. +i!t two ad&antage! : di!ad&antage! of )!ing a %rogra##ing $ang)age a! te wo$e
notation tro)g de&e$o%#ent %roce!!.
11. Wat are te t,%e! of ;M+ notation!"
The types of )M* notations are )se case diagrams, +lass diagrams, Interaction
diagrams, State machine diagrams, #ctivity diagrams.
13. 4an te !,!te# )nder con!ideration can be re%re!ented a! an actor"
15. Wat i! te difference between !cenario : )!e ca!e"
# !cenario is an instance of a use case describing a concrete set of actions.
Scenario! are used as examples for illustrating common cases.
Their focus is on understandability.
# )!e ca!e is an abstraction that describes all possible scenarios involving the described
functionality.
;!e ca!e! are used to describe all possible cases.
Their focus is on completeness.
16. Wat are different #ode$! foc)!ed on !,!te# de&e$o%er!"
The different models are use case models, class models and source code.
17. Wat i! 8otation" E0%$ain wit e0a#%$e.
# notation is a graphical or textual set of rules for representing a model. The Roman
alphabet is a notation for representing words. )M* ,)nified Modeling *anguage -(M.,
/00123, the notation we use throughout this boo!, is an ob$ect&oriented notation for
representing models.
29. 2efine data t,%e! and ab!tract data t,%e!.
# data t,%e is an abstraction in the context of a programming language. 'ata types are
used in typed languages to ensure that only valid operations are applied to specific data
members.
#n ab!tract data t,%e is a special data type whose structure is hidden from the rest of
the system. This allows the developer to revise the internal structure and the
implementation of the abstract data type without impacting the rest of the system.
21. 2efine <neritance
Inheritance is the relationship between a general class and one or more speciali4ed
classes. Inheritance enables us to describe all the attributes and operations that are
common to a set of classes.
22. Wat i! an ab!tract c$a!!" =i&e an e0a#%$e.
5hen a generali4ation serves only the purpose of modeling shared attributes and
operations, that is, if the generali4ation is never instantiated, it is called an ab!tract c$a!!.
#bstract classes often represent generali4ed concepts in the application domain.
6or e0a#%$e, in chemistry, 7en4ene can be considered a class of molecules that belongs
to the abstract class (rganic compound.
2*. 4o#%are o%eration : acti&itie!.
#n o%eration defines something in terms of the specific process or set of validation tests
used to determine its presence and uantity.
#n acti&it, is a set of tas!s that is performed toward a specific purpose. 6or example,
reuirements elicitation is an activity whose purpose is to define with the client what the
system will do.
2/. 2i!ting)i! a%%$ication do#ain : !e$ection do#ain.
The a%%$ication do#ain model is a description of those aspects of the real&world system
that are relevant to the problem under consideration. This model is then used by the
system to represent the real&world concepts it manipulates.
The !e$ection do#ain model is to choose one or more existing domain models or entities
from the !nowledge base, which are expected to serve as the best raw material for further
elaboration.
21. 2efine te ter# >a$!ification and %rotot,%ing.
>a$!ification is the process of demonstrating that relevant details have been incorrectly
represented or not represented at all8 that is, the model does not correspond to the reality
it is supposed to represent.
# techniue for developing a system is %rotot,%ing. 5hen designing the user interface,
developers construct a prototype that only simulates the user interface of a system. The
prototype is then presented to potential users for evaluation, that is, falsification, and
modified subseuently.
23. En$i!t te re$ation!i% to te )!e ca!e diagra#.
)se case diagrams can include four types of relationships such as follows9
+ommunication, inclusion, extension, and generali4ation.
25. ?ow i! )!e ca!e re$ated to a !,!te#"
26. 4o#%are c$a!!e! and object!.
# c$a!! is an abstraction in ob$ect&oriented programming languages. +lasses are
abstractions that specify the common structure and behavior of a set of ob$ects.
Object! are instances of classes that are created, modified, and destroyed during the
execution of the system. #n ob$ect has an identity and stores attribute values.
27. 2efine A!!ociation c$a!! wit e0a#%$e.
*9. Wat i! M)$ti%$icit," =i&e an e0a#%$e"
"ach end of an association can be labeled by a set of integers indicating the number of
lin!s that can legitimately originate from an instance of the class connected to the
association end is called as #)$ti%$icit,. 6or e0a#%$e the association end author has a
multiplicity of l. This means each "mergencyReport ob$ect has exactly one lin! to an
ob$ect of class 6ield(fficer.
*1. Wat are te t,%e! of a!!ociation! in #)$ti%$icit,"
The types of associations in multiplicity are one&to&one association, one&to&many
association, and many&to&many association respectively.
*2. 2efine co#%$e0 tran!ition!.
4o#%$e0 tran!ition! are transitions with multiple source states or multiple target states.
+omplex transitions denote the synchroni4ation of multiple activities or the splitting of
the flow of control into multiple threads.
**. 2ifference between wor' %ac'age and wor' %rod)ct.
# wor' %ac'age describes the wor! products to be produced, the resources needed to
perform the wor!, the expected duration, dependencies on inputs, which are wor!
products produced by other tas!s as well as dependencies on other tas!s.
Wor' %rod)ct! represent the deliverables and intermediate products of the pro$ect.
5or! products are the visible results of wor!.
*/. Wat are te e&ent! inc$)ded in %$anned : )n%$anned co##)nication e&ent!"
The events in planned communication are problem presentation, client reviews, pro$ect
reviews, peer reviews, status reviews, brainstorming, releases and postmortem reviews.
The unplanned communication events are reuests for clarification, reuests for changes
and issue resolution.
*1. En$i!t te conce%t! )!ed in %roject organi-ation.
The concepts used in pro$ect organi4ation are pro$ect organi4ations, roles, tas!s % wor!
products and schedule.
*3. Wat are te acti&itie! addre!!ed for organi-ationa$ and co##)nication !tr)ct)re"
The activities addressed for communication structure are $oining a team, $oining the
communication infrastructure, attending team status meetings and organi4ing client %
pro$ect reviews.
*5. E0%$ain te #ajor t,%e! of interaction in a %roject.
The ma$or types of interaction in a pro$ect are reporting, decision and communication.
*6. 2efine (<) Manage#ent 2e&e$o%#ent (ii) 4ro!! f)nctiona$ r)$e
Manage#ent 2e&e$o%#ent is best described as the process from which managers learn
and improve their s!ills not only to benefit themselves but also their employing
organi4ations.
The cro!!-f)nctiona$ ro$e is also called liaison. The liaison is responsible for
disseminating information along the communication structure from one team to another.
+ross&functional roles are concerned with co&ordination among teams.
*7. Wat t,%e! of $iai!on )!ed b, !)b!,!te# tea#"
They are #:I engineer, document editor, configuration manager and tester.
/9. 2efine ta!'! and wor' %rod)ct!.
Wor' %rod)ct! represent the deliverables and intermediate products of the pro$ect.
5or! products are the visible results of wor!.
# ta!' represents an atomic unit of wor! that can be managed. Tas!s consume resources,
result in wor! products, and depend on wor! products produced by other tas!s.
/1. +i!t te %$anned co##)nication e&ent!.
The events in planned communication are problem presentation, client reviews, pro$ect
reviews, peer reviews, status reviews, brainstorming, releases and postmortem reviews.
/2. Wat i! PER@ 4art" Were it i! )!ed"
# PER@ cart represents a schedule as an acyclic graph of tas!s. :"RT charts are useful
tools for planning a pro$ect and trac!ing its execution.
6igure //&/; is a PER@ cart for the database subsystem. The planned start and duration
of the tas!s are used to compute the critical path, which represents the shortest possible
path through the graph. The length of the critical path corresponds to the shortest possible
schedule, assuming sufficient resources to accomplish in parallel tas!s that are
independent.
/*. 2efine brief$, te e&ent! of )n%$anned co##)nication.
Re()e!t! for c$arification: It represents the bul! of the communication among
developers, clients, and users.
Re()e!t for cange: 'uring a re()e!t for cange, a participant reports a problem and,
in some cases, proposes solutions.
<!!)e re!o$)tion: # flat organi4ation may select a solution through the brainstorming
process.
//. E0%$ain w, #)$ti%$e coice ()e!tionnaire! a! a %ri#ar, need! for e0tracting
infor#ation fro# )!er are not effecti&e for e$iciting re()ire#ent!.
Multiple choice uestionnaires is formali4ed as a primary needs for extracting
information from user which are not effective for eliciting reuirements because of
/1. Wat are te ro$e! a!!igned for a #eeting"
The roles assigned for meeting are group roles, ground roles, and meeting roles.
/3. En$i!t te organi-ationa$ acti&itie!.
The activities addressed for communication structure are $oining a team, $oining the
communication infrastructure, attending team status meetings and organi4ing client %
pro$ect reviews.
/5. 2efine Meeting #in)te!.
Meeting #in)te! represent a portion of the pro$ect history that can be analy4ed after the
pro$ect is completed. Meeting minutes include a section describing the action items
resulting from the meeting ,i.e.3 the items describing actions to be ta!en by the meeting
participants as a conseuence of the meeting.
/6. Wat are te ter#! inc$)ded in a %roject for)#"
/7. Wat i! te difference between c$ient : end )!er"
4$ient is a person or a co&operate group for whom product is developed and sold. They
are the ones who pay for that software. It can also mean someone who receives long term
benefits or services from another person whether or not they pay for them.
End )!er can be any person or a group that uses the software or product once it is sold to
client in their domain. # customer who uses online ban!ing is called as an end user for
that online ban!ing system.
19. Wat i! te difference between cro!! f)nctiona$ tea# and !)b!,!te# tea#"
A cross-functional team, the architecture team, made of
representatives of each team, is responsible for ensuring the
integration of the requirements. 4ro!!-f)nctiona$ tea# made up of and selected
developers ,who will ta!e part in the implementation of the subsystem3. Teams that do
not wor! directly on a subsystem, but rather, accomplish a pro$ect&wide function, are
called cro!!-f)nctiona$ tea#!.
"ach team which negotiates with other teams for the interfaces of the subsystems it needs
is said to be !nown as !)b!,!te# tea#!. "ach subsystem team wor!s with its system
engineering representative to define the metrology reuirements for each of the critical
functional responses they have created.
11. 4an a ro$e be !ared between one or #ore %artici%ant!" W, or w, not"
Roles can be played by two or more participants in front of the group. This is good for
exploring problem solving and provides a shared experience the entire group can discuss
and perhaps replay. It singles out people which may be inappropriate.
;8<@ << A8A+AS<S
12. +i!t te acti&itie! of Re()ire#ent e$icitation.
The activities of reuirement elicitation are identifying actors, identifying scenarios,
identifying use cases, refining use cases, identifying relationship among actors and use
cases, identifying initial analysis ob$ects, and identifying nonfunctional reuirements.
1*. 2efine Boint A%%$ication 2e!ign.
Boint A%%$ication 2e!ign ,<#'3 focuses on building consensus among developers, users,
and clients by $ointly developing the system specification. <oint #pplication 'esign
,<#'3 is a software design methodology developed by I7M to enhance application
design productivity and uality.
1/. 4o#%are f)nctiona$ : non-f)nctiona$ re()ire#ent!.
The f)nctiona$ re()ire#ent! specify what the product must do.
They relate to the actions that the product must carry out in order to satisfy the
fundamental reasons for its existence.
8onf)nctiona$ Re()ire#ent is a constraint on the operation of the system that is not
related directly to a function of the system.
The non&functional reuirements add functionality to the product && it ta!es some amount
of pressing to ma!e a product easy to use, or secure, or interactive.
11. Wat are categorie! of non-f)nctiona$ re()ire#ent! )!ed b, >)rt! Mode$"
The categories of nonfunctional reuirements are9 usability, reliability, robustness, safety,
maintainability, performance, supportability, adaptability, and portability.
13. Wen te re()ire#ent !%ecification i! !aid to be rea$i!tic. traceab$e and &erifiab$e"
The specification is said to be &erifiab$e if, once the system is built, a repeatable test can
be designed to demonstrate that the system fulfills the reuirement.
# system specification is traceab$e if each system function can be traced to its
corresponding set of reuirements.
The reuirement specification is rea$i!tic, if the system can be implemented within
constraints.
15. +i!t te additiona$ categorie! of re()ire#ent b, >)rt! Mode$.
16. 2efine te ter#! =reenfie$d engineering. reengineering. and interface engineering.
In =reenfie$d engineering, the development starts from scratch, no prior system exists,
and the reuirements are extracted from the users and the client. # .reenfield engineering
pro$ect is triggered by a user need or the creation of a new mar!et.
# reengineering pro$ect is the redesign and reimplementation of an existing system
triggered by technology enablers or by new information flow.
#n interface engineering pro$ect is the redesign of the user interface of an existing
system. The legacy system is left untouched except for its interface, which is redesigned
and reimplemented.
17. Wat are te t,%e! of !cenario"
The four types of scenario are #s&is scenarios, =isionary scenarios, "valuation scenarios,
and Training Scenarios.
39. Wat are te !cenario! wic are e0%ected to !)%%ort te ta!' in >R<E82 e0a#%$e"
31. ?ow i! te )!e ca!e identified"
# scenario is an instance of a use case, that is, a use case specifies all possible scenarios
for a given piece of functionality. # use case is initiated by an actor. #fter its initiation, a
use case may interact with other actors as well. # use case represents a complete flow of
events through the system in the sense that it describes a series of related interactions that
result from the initiation of the use case.
32. 4o#%are E0tend and <nc$)de re$ation!i%.
<nc$)de is a 2irected Re$ation!i% between two use cases, implying that the behavior of
the included use case is inserted into the behavior of the including use case.
The first use case often depends on the outcome of the included use case.
The notation is a dashed arrow from the including to the included use case, with the label
>?include@>.
E0tend re$ation!i% indicates that the behavior of the extension use case may be inserted
in the extended use case under some conditions.
In another form of interaction, a given use case ,the extension3 may extend another.
The notation is a dashed arrow from the extension to the extended use case, with the label
>?extend@>.
3*. Wat are te re()ire#ent! for #anaging re()ire#ent e$icitation"
The reuirements for managing reuirement elicitation are, eliciting reuirements from
users9 Knowledge #nalysis of Tas!s ,K#T3, negotiating a specification with clients9 <oint
#pplication 'esign ,<#'3, validating reuirements9 usability testing, and documenting
reuirements elicitation.
3/. ?ow i! @raceabi$it, #aintained"
The traceability lin! is maintained through the development process, because we consider
the maintenance of traceability lin! as one of the documenting reuirements elicitation.
31. Wat i! RA2" Mention it! )!e.
The documentation for the results of the reuirements elicitation activity and the analysis
activity are called as Reuirements #nalysis 'ocument ,R#'3. This document
completely describes the system in terms of functional and nonfunctional reuirements
and serves as a contractual basis between the client and the developers.
33. 2i!ting)i! between Ana$,!i! object #ode$ : 2,na#ic #ode$.
The intention with the ana$,!i! object #ode$ is that it is a means to describe the
architecture, i.e. the main ob$ects that need to be implemented in the completed system.
The notations used are the same as for the reuirements ob$ect model in the reuirements
analysis. #n overview of the notations is given in (b$ect Model Aotation and in State
+hart Aotation. The ana$,!i! object #ode$s are represented by class and ob$ect
diagrams.
@e d,na#ic #ode$ describes the behavior of a distributed parameter system in terms of
how one ualitative state can turn into another. The d,na#ic #ode$, represented by state
chart and seuence diagrams.
35. 2efine Entit,. Co)ndar,. and 4ontro$ Object!
Entit, object! represent the persistent information trac!ed by the system.
Co)ndar, object! represent the interactions between the actors and the system.
4ontro$ object! represent the tas!s that are performed by the user and supported by the
system.
36. 4o#%are S%ecification and =enera$i-ation wit an e0a#%$e.
Reuirement elicitation focuses on describing the purpose of the system. The client, the
developers, and the users identify a problem area and define a system that addresses the
problem. Such a definition is called a reuirements !%ecification and serves as a contract
between the client and the developers.
37. Wat are te acti&itie! tat tran!for# te )!e ca!e! and !cenario! into an ana$,!i!
#ode$"
The activities that transform the use cases and scenarios produced during reuirements
elicitation into an analysis model are,
59. Wat i! 4R4 4ard" E0%$ain it! i#%ortance.
called the 4R4 4ard.
51. ?ow i! a!!ociation identified" =i&e an e0a#%$e.
52. +i!t te %ro%ertie! of a!!ociation!.
5*. State and e0%$ain te t,%e! of aggre!!ion.
5/. Wat are te %ro%ertie! of attrib)te" =i&e an e0a#%$e.
@e %ro%ertie! of attrib)te! are.
51. Wat are te t,%e! of ro$e! for a!!igning re!%on!ibi$it, in doc)#entation"
There are three types of roles for assigning responsibility in documentation such as
generation of information, integration, and review.
53. +i!t te factor! wic enab$e co##)nicating abo)t ana$,!i!.
+ommunicating factors include different bac!ground of participants, different
expectations of sta!eholders, new teams, and evolving system.
55. Crief$, e0%$ain Crain!tor#ing and So$idification
The goal of brain!tor#ing is to generate and evaluate a large number of solutions for a
problem. 7rainstorming is usually done in face&to&face meetings but can also be done via
"&mail or groupware. The fundamental idea behind brainstorming is that solutions
proposed by one participant, however invalid, can trigger additional ideas and proposals
from other participants.
(nce the client and the developers converge on a common idea, define the boundaries of
the system, and agree on a set of standard terms, !o$idification starts. 6unctionality is
organi4ed into groups of use cases with their corresponding interfaces. .roups of
functionality are allocated to different teams that are responsible for detailing their
corresponding use cases. 'uring this stage, iterations are rapid but locali4ed.
56. Wat i! 4$ient Sign-Off" +i!t teir %ro%ertie!.
UNIT III SYSTEM DESIGN
57. ?ow are arcitect)ra$ conce%t! #a%%ed wit !oftware engineering conce%t!"
69. Wat are %rod)ct! of ana$,!i! re!)$t in re()ire#ent #ode$"
61. Wat are te %rod)ct! e0%ected in !,!te# de!ign"
S,!te# de!ign re!)$t! in te fo$$owing %rod)ct!.
62. 2ifferentiate co)%$ing : coe!ion.
4o)%$ing measures the dependencies between two subsystems, whereas coe!ion
measures the dependencies among classes within a subsystem.
In co)%$ing the desirable property of a subsystem decomposition is that subsystems are
as loosely coupled as reasonable, whereas in cohesion the desirable property of a
subsystem decomposition is that it leads to subsystems with high cohesion.
6*. =i&e ;M+ diagra# of S)b!,!te# 2eco#%o!ition.
6/. 4o#%are +a,ering and Partitioning.
# ierarcica$ deco#%o!ition of a system yields an order set of $a,er!. +a,ering is a
grouping of subsystems providing related services, possibly reali4ed using services from
another layer.
Partitioning can be done in two wa,! !)c a! @?E S@A@E, @?E PROBE4@<O8
61. +i!t te de!ign goa$! wic are diffic)$t to #eet wen )!ing c$o!ed arcitect)re wit
#an, $a,er!"
63. 2i!ting)i! o%en and c$o!ed arcitect)re.
In an o%en arcitect)re, a layer can also access layers at deeper levels, whereas in
c$o!ed arcitect)re, each layer can access only the layer immediately below it.
#n example of an open architecture is the Swing user interface tool!it for <ava whereas
an example for closed architecture is the reference model of (pen System +onnection
,(SI3 which consists of seven layers.
65. +i!t te t,%e of arcitect)ra$ !t,$e!.
The types are Repository, ModelB=iewB+ontroller, +lientBServer, :eer&to&peer, Three&tier,
6our Tier, and :ipe % filter.
66. Wat i! Re%o!itor,"
# re%o!itor, is a storage location from which software pac!ages may be retrieved and
installed on a computer. Repositories are typically used for database management
systems, such as a payroll system or ban! system.
67. Wat are te !,!te# de!ign acti&itie! fro# object! to !)b!,!te#"
The system design activities are9 Starting point9 #nalysis model for a Route :lanning
Subsystem, Identifying design goals, and identifying subsystems.
79. +i!t te i!!)e! faced b, !,!te# de!ign acti&itie!.
The issues are, hardwareBsoftware mapping, data management, access control, boundary
conditions, and control flow.
71. Wat are te acti&itie! refining !)b!,!te# deco#%o!ition"
#ctivities refining subsystem decomposition are,
72. 2efine Pro0, de!ign %attern.
The %ro0, %attern is described as one which >decouples clients from their servers by
creating a local proxy, or stand&in, for the less accessible server. 5hen the client needs to
reuest a service from the server, such as retrieving a value, it as!s its local proxy. The
proxy can then marshal a reuest to the original server.C
7*. En$i!t te o%tion! a&ai$ab$e for !torage #anage#ent.
The options for storage management are9 flat files, relational database, and ob$ect&
oriented database respectively.
7/. 2efine bo)ndar, )!e ca!e!.
To distribute use cases among subsystems, where to store data, % how to achieve access
control % ensure security, to decide how the system is started, initiali4ed, and shutdown
and we need to define how we deal with ma$or failures such as data corruption % networ!
outages. )se cases dealing with these conditions are called bo)ndar, )!e ca!e!.
71. Wat i! contro$ f$ow" Wat are #ecani!#! a&ai$ab$e in it"
4ontro$ f$ow is the seuencing of actions in a system. In ob$ect&oriented systems,
seuencing actions includes deciding which operations should be executed and in which
order. These decisions are based on external events generated by an actor or on the
passage of time. There are three possible control flow mechanisms such as :rocedure&
driven control, "vent&driven control and Threads.
73. Wat i! te i#%ortance of acce!! contro$" +i!t te a%%roace! a&ai$ab$e in it"
Acce!! contro$ is a system which enables an authority to control access to areas and
resources in a given physical facility or computer&based information system.
The approaches are global access table, access control list, and capabilities.
75. 2efine d,na#ic acce!! contro$"
In the ban! information system example, consider a bro!er actor who is assigned a set of
portfolios. 7y policy, a bro!er cannot access portfolios managed by another bro!er. In
this case, we need to model access right dynamically in the system, and hence this type of
access is called as d,na#ic acce!! contro$.
76. ?ow i! bo)ndar, )!e ca!e identified"
To have a better idea of how to decompose the system, how to distribute use cases
among, subsystems, where to store data, and how to achieve access control and ensure
security. 5e still need to examine the boundary conditions of the system, that is, to decide
how the system is started, initiali4ed, and shut down, and we need to define how we deal
with ma$or failures, such as data corruption, whether they are caused by a software error
or a power outage.
77. Wat de!ign goa$! tat $ead to te deci!ion tat !torage of con!i!tent object! and$ed
b, dedicated $a,er in * : / tier arcitect)re"
199. W, ) cannot di!%$a, bo)ndar, )!e ca!e d)ring re()ire#ent e$icitation or
ana$,!i!"
191. Wat i! E0ce%tion" En$i!t !o)rce! of it.
#n e0ce%tion is an unexpected event or error that occurs during the execution of the
system. "xceptions are caused by one of three different sources9
# user error, a hardware failure, and a software bug.
192. 2efine E0ce%tion and$ing wit an e0a#%$e.
E0ce%tion and$ing is the mechanism by which a system treats an exception. In the case
of a user error, the system should display a meaningful error message to the user, such
that heBshe can correct her input. In the case of a networ! lin! failure, the system needs to
save its temporary state in order to recover once the networ! comes bac! on line.
19*. Wat i! S22" E0%$ain it! i#%ortance.
System design is documented in the S,!te# 2e!ign 2oc)#ent (S22). The S22 is used
to define interfaces between teams of developers and as reference when architecture&level
decisions need to be revisited. It describes design goals set by the pro$ect, the subsystem
decomposition, the hardwareBsoftware mapping, the data management, the access control,
control flow mechanisms, and boundary conditions.
19/. +i!t te !)b!ection! a&ai$ab$e in %ro%o!ed !,!te# arcitect)re.
The subsections available are9 overview, subsystem decomposition, persistent data
management, access control % security, global software control, and boundary
conditions.
191. Wat are te #ain ro$e! for a!!igning re!%on!ibi$itie! in !,!te# de!ign"
The main role! for assigning responsibilities in system design are architect, architecture
liaisons, and the document editorBconfiguration managerBreviewer.
193. W, co##)nication i! diffic)$t and wat are te !o)rce! of co#%$e0it,"
+ommunication during system design should be less challenging than during analysis9
The functionality of the system has been defined8 pro$ect participants have similar
bac!grounds and by now should !now each other better. +ommunication is still difficult,
due to new sources of complexity such as si4e, change, level of abstraction, reluctance to
confront problems, and conflicting goals and criteria.
195. 2efine >aDade de!ign %attern.
The facade %attern is a software engineering design pattern commonly used with
(b$ect&oriented programming. ,The name is by analogy to an architectural facade.3
# facade is an ob$ect that provides a simplified interface to a larger body of code, such as
a class library. # facade can9
ma!e a software library easier to use, understand and test, since the facade has convenient
methods for common tas!s8
ma!e code that uses the library more readable, for the same reason8
reduce dependencies of outside code on the inner wor!ings of a library, since most code
uses the facade, thus allowing more flexibility in developing the system8
wrap a poorly&designed collection of #:Is with a single well&designed #:I ,as per tas!
needs3.