First,
the design pattern is what (1) the problem of repeated solutions (2) to
enhance the flexibility of the software (3) to adapt to the changing
software
(1) learn from the excellent code design, help to improve the code
design capabilities (2) JDK design reflects the majority of the design
pattern is to learn the design pattern of a better way (3 ) Can be more
in-depth understanding of JDK
Third, the relationship between class inheritance, commission, dependency, aggregation, combination
Fourth, the introduction of the way (1) Role: to summarize a design
pattern of the basic points (2) JDK embodied: a design pattern in the
JDK is how to reflect the (3) class diagram: a design pattern in the JDK
corresponding to the class Figure
Fifth, the classic design patterns in the implementation of the JDK 1.Singleton (singleton) Role: Guaranteed class has only one instance; provide a global access point JDK embodies: (1) Runtime (2) NumberFormat Class Diagram: 2.Factory (static factory) effect: (1) instead of the constructor to create the object (2) method name than the constructor function is clear JDK embodies: (1) Integer.valueOf (2) Class.forName Class Diagram:
3.Factory Method (factory method) Role: Subclass determines which class is instantiated JDK embodied: Collection.iterator method class diagram:
4.Abstract Factory (abstract factory) Role: Create a class of objects JDK embodies: (1) java.sql package (2) UIManager (swing appearance) Class Diagram: 5.Builder (constructor) effect: (1) the construction logic mentioned in a separate class (2) separation of the class structure logic and performance JDK embodied: DocumentBuilder (org.w3c.dom) Class Diagram:
6.Prototype (prototype) effect: (1) copy object (2) shallow copy, deep copy JDK embodied: Object.clone; Cloneable Class Diagram:
7.Adapter (adapter) Function: Make incompatible interface compatible JDK embodies: (1) java.io.InputStreamReader (InputStream) (2) java.io.OutputStreamWriter (OutputStream) Class Diagram:
8.Bridge (bridge) The role: the abstract part and its realization part of the separation, so that they can be independent changes JDK embodies: Handler and Formatter in java.util.logging Class Diagram: 9.Composite (combination) Role: Consistent treatment of composite objects and independent objects JDK embodies: (1) org.w3c.dom (2) javax.swing.JComponent # add (Component) Class Diagram:
10.Decorator (decorator) Role: add new features to the class; prevent class inheritance from the explosive growth JDK embodies: (1) java.io package (2) java.util.Collections # synchronizedList (List) Class Diagram: 11.Façade (appearance) effect:
(1) encapsulates a set of interactive classes, consistently providing
an interface (2) encapsulating subsystems, simplifying subsystem calls JDK embodied: java.util.logging package class diagram: 12.Flyweight Role: shared object, saving memory JDK embodies: (1) Integer.valueOf (int i); Character.valueOf (char c) (2) String constant pool diagram: 14.Proxy (proxy) effect:
(1) transparent call by the proxy object, without having to know the
details of the complex implementation (2) to increase the function of
the proxy class JDK embodied: dynamic agent; RMI Class Diagram: 15.Iterator (iterator) Role: Separate the set of iterations and the collection itself JDK embodied: Iterator, Enumeration interface class diagram: 16.Observer (observer) Action: Notify the object state change JDK embodies: (1) java.util.Observer, Observable (2) Listener in Swing Class Diagram: 17.Mediator (coordinator) Role: Used to coordinate the operation of multiple classes JDK embodies: Swing's ButtonGroup Class Diagram: 18.Template method (template method) Role: the definition of the structure of the algorithm, sub-class only to achieve different parts JDK embodied: ThreadPoolExecutor.Worker Class Diagram: 19.Strategy (strategy) Role: provide different algorithms JDK in the expression: ThreadPoolExecutor in the four types of rejection strategy class: 20.Chain of Responsibility
Action: The request is handled by the object on the chain, but the
client does not know which objects the request will be processed JDK embodies: (1) java.util.logging.Logger delegates log to parent logger (2) ClassLoader delegate model class diagram: 21.Command (command) effect: (1) package operation, so that the interface is consistent (2) the caller and receiver in space and time on the decoupling JDK embodied: Runnable; Callable; ThreadPoolExecutor Class Diagram: 22. Null Object (empty object) Function: do not need to empty each time, treat the null value, as to treat an object of the same interface JDK embodied: Collections.EMPTY_LIST Class Diagram: 23.State (state)
Role: the main object and its state separation, the state object is
responsible for the state of the main object conversion, so that the
main object class function JDK reflected: no class map found: 24.Visitor (Visitor) Role: heterogeneous class to add polymerization operations; collecting aggregated data JDK in the embodiment: no class map: 25.Interpreter (interpreter) Function: Use a set of classes to represent a rule JDK embodied: java.util.regex.Pattern Class diagram: four operations 26.Memento (memo) Role: to maintain the object state, if necessary, can be restored JDK reflected: no class map found: Sixth, reference 1. Design Pattern (GoF) 2. Software Architecture Design Patterns in Java 3. JDK 5 Documentation 4. http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns 5. http://java.csdn.Net/a/20101129/282644.html
Microservices are small, independent services that work together. In
other words, these services are small, highly decoupled and focus on
doing a small task at a time.
Follow the Single Responsibility Principle
Resilient/Flexible – failure in one service does not impact other
services.
High scalability – demanding services can be deployed in multiple
servers to enhance performance and keep away from other services so that
they don’t impact other services
Easy to enhance– less dependency and easy to change and test
Low impact on other services – being an independent service, this has less chance to impact other services
Easy to understand – since they represent the small piece of functionality
Ease of deployment– microservice support agile development
Freedom to choose technology– allows to choose technology, best suited for a particular functionality
Process-centric components– Each
microservice typically runs in a separate process as distinct from a
thread within a larger process. This ensures the component is neither
too small nor too large.
Data-driven interfaces – with a few inputs and
outputs. In practice, most productive Microservices typically have only a
few inputs and outputs (often less than 4 each). Communication between Microservices is document-centric an important feature of Microservices architecture.
Focused functionality :A Microservice is typically
organized around a single, focused capability: e.g. access/update a
Database, Cache input data, update a Bank account, Notify patients, etc.
Independent interfaces: Each Microservice typically has a GUI Associated with itself, for end-user interaction and configuration. Each Microservice is essentially a ‘product’ in its own right in that it
has defined inputs and outputs and defined, non-trivial fun
Easier Governance : since each Microservice runs in its
own process and shares no dependencies with others, it can be
monitored, metered and managed individually.
Decentralized Data Management : Each Microservice
can store data as it pleases : a given Microservice can use SQL, a
second MongoDB, a third a Mainframe database, etc.
Automated Deployment and Infrastructure Automation :
Implementation independence allows assemblies of Microservices can be
‘moved’ from one deployment environment to another (for example,
Development —> QA —> Stating —> Production), based just on
profile settings.
Orchestration and Choreography: Synchronous vs. Asynchronous : If the Microservices are orchestrated using a classic synchronous
mechanism (blocking calls, each waiting for downstream calls to return),
potential performance problems can occur as the call-chain increases in
size. A more efficient mechanism is to use an asynchronous protocol,
such as JMS or any other enterprise-messaging protocol/tool
(IBM MQ, MSMQ, etc.) to choreograph the Microservices. This approach
ensures that there are no bottlenecks in the final application-system
since most of the communication is via non-blocking asynchronous calls,
with blocking, synchronous calls limited to things like
user-interactions. A simple rule of thumb is to avoid as many blocking
calls as one can.
Disadvantages to using a microservices architecture :
Services form information barriers.
The architecture introduces additional complexity and new problems to deal with, such as network latency, message formats, load balancing, and fault tolerance; ignoring one of these belongs to the "fallacies of distributed computing."
Testing and deployment are more complicated.
The complexity of a monolithic application is only shifted into the network, but it persists.
Too-fine-grained microservices have been criticized as an anti-pattern.
Overcoming the Domino Effect (Cascade Failure) When working with
microservices, it’s possible for a microservice you don’t even know
about to cause a cascade failure. When microservice A fails and there is
no available failover, microservice B could also fail, which might
bring microservice C to a standstill as well. The point is to be proactive in assuming that failures will occur in order to avoid potential cascade failures.
Unified Modeling Language, a standard language for designing and
documenting a system in an object-oriented manner. It has nine diagrams
which can be used in design document to express design of software
architecture.
Use case diagram answers what system does from the user point of
view. Use case answer ‘What will the system do?’. Use cases are mainly
used in requirement document to depict clarity regarding a system. There
are three important parts in a use case scenario, actor and use case. Scenario: A scenario is a sequence of events which happen when a user interacts with the system. Actor: Actor is the who of the system, in other words the end user. Use Case: Use case is task or the goal performed by
the end user. Below figure ‘Use Case’ shows a simple scenario with
‘Actor’ and a ‘Use Case’. Scenario represents an accountant entering
accounts data in the system. As use case’s represent action performed
they are normally represented by strong verbs.
Actor’s are represented by simple stick man and use case by oval shape as shown in figure ‘Use Case’ below.
Actors are further classified in to two types primary and secondary
actors. Primary actors are the users who are the active participants and
they initiate the user case, while secondary actors are those who only
passively participate in the use case.
Use case’s have two views of representation in any requirement
document. One is the use case diagrams and the other is a detail step
table about how the use case works. So it’s like a pair first an over
view is shown using a use case diagram and then a table explaining the
same in detail. Below is a simple ‘login’ use case shown
diagrammatically and then a detail table with steps about how the use
case is executed.
Figure: Login Use Case
Use Case
Rel001
Use Case Name
Login
Description
This uses depicts the flow of how user will log-in into the chat application.
Primary Actor
Simple chat user.
Trigger
User types chat application on URL of the browser.
Pre-condition
NA
Assumption
No password is currently present for the system
Rooms will remain constant as explained in the assumption section of this document
Failed End conditions
Duplicate user name is not allowed in the chat application.
Action
User clicks on the log-in button.
Main Scenario
User types chat application on URL of the browser which in turn opens the main page.
In the main page of application user is popped up with ‘Enter user name’ option and various ‘rooms’ option drop down menu.
User then types the name and selects one of the room from drop down menu and then clicks on the ‘Log-in’ button.
Application then checks whether the user name is unique in the
system if not then user is popped up with error message that “user
already exist”.
After entering the unique name the user is finally logged in the application.
Action
NA
Alternate Scenario
NA
Success Scenarios
1. Opens page of a selected room in that other user names and their messages can be seen.
Note and Open Issues
NA
Table: Login use case table
Note: You must be wondering why we have this pair
why not just a use case table only. Use case diagrams are good to show
relationship between use case and they also provide high over view. The
table explanation of a use case talks details about the use case. So
when a developer or a user is reading a requirement document, he can get
an overview by looking at the diagram if he is interested he can read
the use case tables for more details.
‘Extend’ and ‘Include’ define relationships between use cases. Below
figure ‘Extend and Include’ shows how these two fundamentals are
implemented in a project. The below use case represents a system which
is used to maintain customer. When a customer is added successfully it
should send an email to the admin saying that a new customer is added.
Only admin have rights to modify the customer. First lets define extend
and include and then see how the same fits in this use case scenario.
Include: Include relationship represents an invocation of one use
case by the other. If you think from the coding perspective its like one
function been called by the other function.
Extend: This relationship signifies that the extending use case will
work exactly like the base use case only that some new steps will
inserted in the extended use case.
Below figure ‘Extend and Include’ shows that ‘add customer’ is same
as the ‘add discounted customer’. The ‘Add discounted customer’ has an
extra process, to define discount for the discounted customer which is
not available for the simple customer. One of the requirements of the
project was that when we add a customer, the system should send an
email. So after the customer is added either through ‘Add simple
customer’ use case or ‘Add discounted customer’ use case it should
invoke ‘send a email’ use case. So we have defined the same with a
simple dotted line with <> as the relationship.
Figure: Extend and Include
Note: One of the points to be noted in the diagram
‘Extend and Include’ is we have defined inheritance relationship between
simple and admin user. This also helps us defining a technical road map
regarding relationships between simple and admin user.
Class diagram
Class is basically a prototype which helps us create objects. Class
defines the static structure of the project. A class represents family
of an object. By using Class we can create uniform objects.
In the below figure you can see how the class diagram looks.
Basically there are three important sections which are numbered as shown
in the below. Let’s try to understand according to the numbering:
Class name: This is the first section or top most section of the Class which represents the name of the Class (clsCustomer).
Attributes: This is the second section or the middle section of the class which represents the properties of the system.
Methods: This section carries operation or method to act on the attributes.
Figure: Three sections of the class
Now in the next section we will have a look on Association relationship between these classes.
In order to represent visibility for properties and methods in class
diagram we need to place symbols next to each property and method as
shown in figure ‘Private, Public and Protected’. ‘+’ indicates that it’s
public properties/methods. ‘-‘indicates private properties which means
it can not be accessed outside the class. ‘#’ indicate protected/friend
properties. Protected properties can only be seen within the component
and not outside the component.
A single Class cannot represent the whole module in a project so we need
one or more classes to represent a module. For instance, a module named
‘customer detail’ cannot be completed by the customer class alone , to
complete the whole module we need customer class, address class, phone
class in short there is relationship between the classes. So by grouping
and relating between the classes we create module and these are termed
as Association. In order to associate them we need to draw the arrowed
lines between the classes as shown in the below figure.
In the figure ‘Order is paid by payments class’, we can see Order
class and the Payment class and arrowed line showing relationship that
the order class is paid using payment class in other words order class
is going to be used by payment class to pay the order. The left to right
marked arrow basically shows the flow that order class uses the payment
class.
In case payment class using the order class then the marked arrow should be right to left showing the direction of the flow.
Figure:- Order is paid by Payments class
There are four signs showing the flow:-
Figure: Direction signs in UML
Multiplicity
Multiplicity can be termed as classes having multiple associations or
one class can be linked to instances of many other classes. If you look
at the below figure the customer class is basically associated with the
address class and also observes the notations (*, 0 and 1).If you look
at the right hand side the (1….*) notation indicates that at least one
or many instance of the address class can be present in the customer
class. Now towards left hand side we have (0….*) notation indicating
that address class can exist without or many customer class can link
him.
In order to represent multiplicity of classes we have to show notations like (1….*), (0….*) as shown in below figure. Note: ‘*’ means “many” where as ‘(0, 1)’ means “(zero or at least one)” respectively.
In this Association there are two types mainly Aggregation Association and Composition Association. Aggregation Association signifies that the whole
object can exist without the Aggregated Object. For example in the below
figure we have three classes university class, department class and the
Professor Class. The university cannot exist without department which
means that university will be closed as the department is closed. In
other words lifetime of the university depend on the lifetime of
department.
In the same figure we have defined second Association between the
department and the Professor. In this case, if the professor leaves the
department still the department continues in other words department is
not dependent on the professor this is called as Composition
Association. Note: The filled diamond represents the aggregation
and the empty diamond represents the composition. You can see the figure
below for more details.
When we try to show Aggregation and Composition in a complete project
the diagram becomes very complicated so in order to keep it simple we
can use Composite structure diagram. In the below figure we have shown
two diagrams one is normal diagram other is Composite structure diagram
and the simplicity can easily be identified. In the composite diagram
the aggregated classes are self contained in the main class which makes
it simpler to read.
Figure: Composite Structure diagram
Reflexive associations
In many scenarios you need to show that two instances of the same
class are associated with each other and this scenario is termed as
Reflexive Association. For instance in the below figure shows Reflexive
Association in the real project. Here you can see customer class has
multiple address class and addresses can be a Head office, corporate
office or Regional office. One of the address objects is Head office and
we have linked the address object to show Reflexive Association
relationship. This is the way we can read the diagram Regional address
object is blocked by zero or one instance of Head office object.
Business entity objects represent persistent information like tables
of a database. Just making my point clearer they just represent data and
do not have business validations as such. For instance below figure
‘Business entity and service’ shows a simple customer table which with
three fields ‘Customer Code’,’ Customer Address’ and ‘Phone Number’. All
these fields are properties in ‘ClsCustomer’ class. So ‘ClsCustomer’
class becomes the business entity class. The business entity class by
itself can not do anything it’s just a place holder for data. In the
same figure we have one more class ‘ClsServiceCustomer’. This class
aggregates the business entity class and performs operations like
‘Add’,’ Next’ (Move to next record), ‘Prev’ (Move to previous record)
and ‘GetItem’ (get a customer entity depending on condition).
With this approach we have separated the data from the behavior. The
service represents the behavior while the business entity represents the
persistent data.
System entity class represents persistent information which is
related to the system. For instance in the below figure ‘System entity
and service class’ we have a system entity class which represents
information about ‘loggedindate’ and ‘loggedintime’ of the system
registry. System service class come in two flavors one is it acts like a
wrapper in the system entity class to represent behavior for the
persistent system entity data. In the figure you can see how the
‘ClsAudit’ system entity is wrapped by the ‘ClsAuditSytem’ class which
is the system service class. ‘ClsAuditSystem’ adds ‘Audit’ and
‘GetAudit’ behavior to the ‘ClsAudit’ system entity class.
Figure: System entity and service class
The other flavor of the system service class is to operate on
non-persistent information. The first flavor operated on persistent
information. For instance the below figure ‘Non-persistent information’
shows how the class ‘ClsPaymentService’ class operates on the payment
gateway to Check is the card exists , Is the card valid and how much is
the amount in the card ?. All these information are non-persistent. By
separating the logic of non-persistent data in to a system service class
we bring high reusability in the project.
Figure: Non-persistent information
Note: The above question can be asked in interview from the
perspective of how you have separated the behavior from the data. The
question will normally come twisted like ‘How did you separate the
behavior from the data?’.
In Generalization and Specialization we define the parent-child
relationship between the classes. In many instance you will see some of
the classes have same properties and operation these classes are called
super class and later you can inherit from super class and make sub
classes which have their own custom properties. In the below figure
there are three classes to show Generalization and Specialization
relationship. All phone types have phone number as a generalized
property but depending upon landline or mobile you can have wired or
simcard connectivity as specialized property. In this diagram the
clsphone represent Generalization whereas clslandline and clsmobile
represents specialization.
Interface is represented by <> in the class
diagram. Below figure ‘Interface in action’ shows we have defined an
interface ‘IContext’. Note the ‘<>’ represents an
interface. If we want to show that the interface is used in a class we
show the same with a line and a simple circle as shown in figure
‘Interface in Action’ below.
Figure: Interface in action
Abstract classes are represented by ‘{abstract}’ as shown in figure ‘Abstract classes in action’.
Class represents shows the static nature of the system. From the
previous question you can easily judge that class diagrams shows the
types and how they are linked. Classes come to live only when objects
are created from them. Object diagram gives a pictorial representation
of class diagram at any point of time. Below figure ‘Object diagram’
shows how a class looks in when actual objects are created. We have
shown a simple student and course relationship in the object diagram. So
a student can take multiple courses. The class diagram shows the same
with the multiplicity relationship. We have also shown how the class
diagram then looks when the objects are created using the object
diagram. We represent object with Object Name: Class Name. For instance
in the below figure we have shown ‘Shiv : ClsStudent’ i.e ‘Shiv’ is the
object and ‘ClsStudent’ the class. As the objects are created we also
need to show data of the properties, the same is represented by
‘PropertyName=Value’ i.e. ‘StudentName=Shiv’.
Figure: Object diagrams
The diagram also states that ‘ClsStudent’ can apply for many courses.
The same is represented in object diagram by showing two objects one of
the ‘Computer’ and the other of ‘English’. Note: Object diagrams should only be drawn to
represent complicated relationship between objects. It’s possible that
it can also complicate your technical document as lot. So use it
sparingly.
Sequence diagram shows interaction between objects over a specific
period time. Below figure 'Sequence diagram' shows how a sequence
diagram looks like. In this sequence diagram we have four objects
'Customer','Product','Stock' and 'Payment'. The message flow is shown
vertically in waterfall manner i.e. it starts from the top and flows to
the bottom. Dashed lines represent the duration for which the object
will be live. Horizontal rectangles on the dashed lines represent
activation of the object. Messages sent from a object is represented by
dark arrow and dark arrow head. Return message are represented by dotted
arrow. So the figure shows the following sequence of interaction
between the four objects:
Customer object sends message to the product object to request if the product is available or not.
Product object sends message to the stock object to see if the product exists in the stock.
Stock object answers saying yes or No.
Product object sends the message to the customer object.
Customer object then sends a message to the payment object to pay money.
Payment object then answers with a receipt to the customer object.
One of the points to be noted is product and stock object is not active when the payment activity occurs.
Figure: Sequence diagram
Messages in sequence diagrams
There are five different kinds of messages which can be represented by sequence.
Synchronous and asynchronous messages
Synchronous messages are represented by a dark arrow head while
asynchronous messages are shown by a thin arrow head as shown in figure
‘Synchronous and Asynchronous’.
Figure: Synchronous and Asynchronous
Recursive message
We have scenarios where we need to represent function and subroutines
which are called recursively. Recursive means the method calling
himself. Recursive messages are represented by small rectangle inside a
big rectangle with an arrow going from the big rectangle to the small
rectangle as shown in figure ‘Recursive message’.
Figure: Recursive message
Message iteration
Message iteration represents loops during sequences of activity.
Below figure ‘message iteration’ shows how ‘order’ calls the ‘orderitem’
objects in a loop to get cost. To represent loop we need to write ‘For
each <
Figure: Message iteration
Message constraint
If we want to represent constraints it is put in a rectangle bracket
as shown in figure ‘message constraint’. In the below figure ‘message
constraint’ the ‘customer’ object can call ‘book tickets’ only if the
age of the customer is greater than 10.
Figure: Message constraint
Message branching
Below figure ‘message branching’ shows how ‘customer’ object have two
branches one is when the customer calls save data and one when he
cancels the data.
Figure: Message branching
Doing Sequence diagram practically
Let’s take a small example to understand sequence
diagram practically. Below is a simple voucher entry screen for accounts
data entry. Following are the steps how the accountant will do data
entry for the voucher:-
Accountant loads the voucher data entry screen. Voucher screen loads
with debit account codes and credit account codes in the respective
combo boxes.
Accountant will then fill in all details of the voucher like voucher
description, date, debit account code, credit account code,
description, and amount and then click ‘add voucher’ button.
Once ‘add voucher’ is clicked it will appear in the voucher screen
below in a grid and the voucher entry screen will be cleared and waiting
for new voucher to be added. During this step voucher is not added to
database it’s only in the collection.
If there are more vouchers to be added the user again fills voucher and clicks ‘add voucher’.
Once all the vouchers are added he clicks ‘submit voucher’ which finally adds the group of vouchers to the database.
Below figure ‘Voucher data entry screen’ shows pictorially how the screen looks like.
Figure: Voucher data entry screen
Figure ‘Voucher data entry sequence diagram’ shows how the sequence
diagram looks like. Below diagram shows a full sequence diagram view of
how the flow of the above screen will flow from the user interface to
the data access layer. There are three main steps in the sequence
diagram, let’s understand the same step by step. Step 1:- The accountant loads the voucher data entry
screen. You can see from the voucher data entry screen image we have
two combo boxes debit and credit account codes which are loaded by the
UI. So the UI calls the ‘Account Master’ to load the account code which
in turn calls the data access layer to load the accounting codes. Step 2:- In this step the accountant starts filling
the voucher information. The important point to be noted in this step is
that after a voucher is added there is a conditional statement which
says do we want to add a new voucher. If the accountant wants to add new
voucher he again repeats step 2 sequence in the sequence diagram. One
point to be noted is the vouchers are not added to database they are
added in to the voucher collection. Step 3:- If there are no more vouchers the
accountant clicks submit and finally adds the entire voucher in the
database. We have used the loop of the sequence diagram to show how the
whole voucher collection is added to the database.
Collaboration
diagrams provide the same information as shown by sequence diagram but
they show it in a different way. In sequence diagram we pay more
attention to the time and sequence order, but in collaboration diagram
we pay more emphasis on the interaction messages between the objects.
Figure
‘Collaboration diagrams’ shows how a collaboration diagram looks like.
Below are some points you can easily pick up looking at the figure:-
• Objects are represented in rectangle.
•
Messages are represented by an arrow and sequence number. For instance
in figure ‘collaboration diagrams’ we can see the ‘order product’ has a
arrow which shows that the message is sent from the customer object to
the product and ‘1’ represents that it’s the first messages.
• Conditional statements are denoted by square brackets ‘[‘.
•
We can also group sequence numbers by grouping them using decimals. For
instance ‘Pay by master’ and ‘Pay by Visa’ are all grouped in to
message sequence number ‘3’ (‘Do payment’). So they are denoted by 3,3.1
and 3.2 respectively.
Figure: - Collaboration diagrams
You can represent the for each loop using the ‘for each’ keyword as shown in below figure ‘for each in collaboration’.
Figure: - For each in collaboration
Note: - Try drawing a collaboration
diagram for the same voucher data entry screen. Sequence and
collaboration diagrams are also called as iteraction diagrams.
Activity diagram are used to
capture complicated process flows in a system. Below figure ‘Activity’
shows a simple activity diagram. Some of the points which you can easily
note from the activity diagram figure are:-
• Start of an activity is denoted by a dark circle.
• End of an activity is denoted by a dark circle inside a white circle.
• Activities are denoted by simple oval rectangles.
Figure: - Activity
A decision in activity diagram is as shown figure
‘Decision in Activity Diagram’. Figure shows the condition in a ‘[‘
(Square bracket). So the first activity is ‘Check Age’, if the age is
greater than 16 then we can go for ‘Adult Movie’ activity or else we
need to execute the ‘Kids Movie’ activity.
Figure: - Decision in Activity Diagram
There are situations in project where we need to
execute two parallel activities in a project. A solid bold line
represents from where the activities will split and execute in parallel
and then again a solid line is where the parallel activities will meet.
For instance in the below figure ‘Parallel Processing’ we can see how
‘Make lemon juice’ and ‘Make Ginger Juice’ activities are executed in
parallel.
Figure: - Parallel Processing
In big and complex activity diagrams it’s very difficult
to figure out which object is responsible for which activities. This
problem is solved by ‘Swimlanes’. Consider the below figure ‘Without
Swimlanes’. The whole activity diagram looks very complex and it’s very
difficult to figure out which object is responsible for which activity.
Figure: - Without Swimlanes
Now see the below figure ‘With Swimlanes’ we have
partitioned the activity to the respective objects like Customer, Stock,
Order processing, Payment and Invoice. These partitions are termed as
‘Swimlanes’ , so if you feel that the activity diagram is complex think
about using ‘Swimlanes’ it can really make your activity diagram
readable.
State
diagram depicts different states that an object goes through during
their life cycle. State diagram depicts how an object responds to
events. We think state diagrams as optional and should be used if your
project has scenarios where the object goes through lot of complicated
states and transitions. If your project does not have such kind of
scenarios then sequence, collaboration or activity would be sufficient
to meet your needs. So all objects have states and an object moves from
one state to other state when there is some event or transition.
There
are three important things when we consider state of an object event,
guard and action. Let’s first define these three things: - .
Action: - Action triggers an object state from one state to another.
Event: - Event triggers the action.
Guard: - Guard is condition on which it evaluates which action to be triggered.
These
three things are principle component of state chart diagrams. Below
figure ‘Types of event and action’ shows how they are represented in
state chart diagrams.
Figure: - Types of Event and Action
There are three ways by which we can represent the same.
Type 1:-
This methodology of writing is used when we need to map an event with
action using a guard. For instance in the above figure ‘Types of Event
and Action’ shows the event mouse click, guard double click and the
resulting action open folder.
Type 2:- The
guard is optional. For instance sometimes we only have events and
actions, i.e. with out the guard. For instance when the even ‘On’
happens the action is that ‘Light Bulb is on’.
Type 3:-
This type of representation shows an infinite loop for an action. For
instance the ‘Watch will be running’ infinitely during a state, as shown
in figure ‘Type of Event and Action’.
Now that we know how to
write event, actions and guard, let’s see how state diagram looks like.
Below figure ‘State example’ shows how a state looks like. It’s an oval
rectangle as shown below. In order to show a transition we need to show
an arrow from one state to other state as shown in figure ‘State
example’.
Figure: - State example
Below figure ‘Sample state chart’ shows a simple
state chart diagram. Some points which are immediately visible from the
diagrams are as follows:-
• A dark black arrow indicates start of a state chart diagram.
• A dark circle with a white circle outside indicates end of a state chart diagram.
• Circular rectangle indicates state while arrows indicate events / transitions.
Figure: - Sample state chart
State is represented as shown in figure ‘Basic
element of state diagram’. It’s a simple rectangle which is rounded. In
the top section we give the state name. The below section is optional
which has ‘do/action’. It represents a long running activity when the
object goes through this state.
Stereotypes are a way to define variations on
existing UML model. This variation is brought in to place to extend UML
in a consistent manner. They are displayed in double less than and
double greater than sign with a simple text as shown below. The below
figure shows at the left hand side a class diagram with out stereo types
while the right hand side shows with stereo types. You can easily make
out how the class diagram is readable with stereo types. For instance
the ‘Customer()’ can be mistaken for a method but we have clarified that
it’s a constructor by using stereo types.
Figure: - Stereotypes
Below are some of the commonly used stereo types while writing UML.
<>:- Used to represent a UI system in a application. <> :- represents a database in a application. <> :- A table with in database. <> :- A reusable library or function. <> :- Physical file on a folder. <> :- A software component which can be executed. <> :- Represents a web service. <> :- Java database connectivity , a JAVA API to connect to database. <> :- Open database connectivity , a Microsoft API to connect to database.
Packages are like folders in a system which allows
you to logically group UML diagrams. They make complex UML diagram
readable. In actual projects they are used to logically group use cases
and classes. So we can say there are two types of package diagrams one
is class package diagram and other is use case package diagram. Package
diagram depict a high level of overview for class and use cases.
Class package diagram: -
Class package diagram are used to logical group classes. You can think
that package technically map to ‘Package’ in JAVA and ‘Namespaces’ in C#
and VB.NET. Packages are denoted by small rectangle on a big rectangle
as shown in figure ‘Package diagram’. One of the points to be noted is
the stereotypes. We have numbered the figure so that we can understand
it better.
1 – We are using the MVC (Model View controller)
framework. So we have denoted this package using the << Framework
>> stereo type. Refer the commonly used stereo type table
discussed in the previous sections.
2 and 3 – ‘Book tickets’ is
the second package which inherits from the MVC model. The stereo type is
‘<>’ which means it’s a user interface.
4 – A simple line shows a link between two classes stating that one class package uses the other class package.
5 – This package is collection of the booking engine library.
6 – The final package is the database.
Figure: - Package diagram
As said before packages are nothing but collection
of logical classes or any UML entity. We have shown the detail of the
above package diagram. We should restrict from using package diagram for
showing the in depth architecture as it can become very complicated.
For instance the below diagram ‘Detail Package diagram’ shows how
complicated it can look if use the package diagram to show in depth
architecture. To avoid complication its good to only draw an over all
diagram as shown in ‘Package diagram’.
Figure: - Detail Package diagram
Use case package diagram: - The way we have
logically grouped classes we can also use the package diagram to
logically group use cases. Below figure shows how a use case package
diagram looks like.
Component diagrams achieve the same objective like
package diagrams. They show the dependencies among software components.
Below figure ‘Component diagram’ shows a sample component diagram for
simple data entry application which uses a web service to interact with
the database. We have numbered the steps to understand the details of
the component diagram.
1 – Two rectangles are shown to represent a component of a system.
2 – Stereo types are used to denote what kind of system it represents.
3
– A line with a circle denotes an interface by which the external world
can interact with the component. For instance in the figure we have
represented a ‘Customer Web service’ which can is interacted by using
XML.
Deployment diagrams represents an overall static
view of how software and hardware nodes in the application. They show
what the hardware is and which components are installed on which
hardware. In deployment diagram we represent the hardware with a solid
box and simple underlined text description showing which hardware is it.
You can have more than one component on a single hardware. So the
browser is an application UI which resides on the workstation computer
and the database and web server resides on the web server hardware.
Deployment diagram can be more complex with firewalls, payment gateways,
PDA devices, VPN etc.
In actual projects we do not draw all the diagrams.
Every UML diagram is made for a purpose. It completely depends on what’s
the nature of the project. In short you should ask yourself questions
like, is this diagram important, what’s my need etc. So below is a flow
which you can follow in your project, again as we said it depends on
what kind of scenario you want to depict.
Figure: - UML flow in actual projects
• The first step is to derive use cases from the requirement documents.
•
Once use cases are derived we need to decide the messages which will
flow in the system. This can be done using interaction diagrams. If you
need to know the object creation life times we use the sequence diagram
and if we want to concentrate on the messages we use the collaboration
diagrams. So depending on scenario we need to make a choice which
diagram we need to draw.
• Now that we are clear about messages we can draw class diagrams to depict the static part of the project i.e. classes.
• If we find any complicated class relationships we draw object diagrams.
• If we need to depict any complicated code we need to represent same with a activity diagram.
•
Finally to give an overview of the project we can use package diagram,
component or deployment diagram. As said before we can use combination
of component and deployment diagram to give a overview of the
architecture.
Note: - Never say in a interview that
we have used all UML diagrams in the technical document. It can give a
very bad impression. As said every UML diagram is drawn according to the
scenario of the project.
UML interview questions
Question: What is UML? Answer: UML stands for the Unified Modeling Language.
It is a graphical language for 1) visualizing, 2) constructing, and 3) documenting the artifacts of a system.
It allows you to create a blue print of all the aspects of the system, before actually physically implementing the system.
Question:What are the advantages of creating a model? Answer: Modeling is a proven and well-accepted engineering technique which helps build a model.
Model is a simplification of reality; it is a blueprint of the actual system that needs to be built.
Model helps to visualize the system.
Model helps to specify the structural and behavior of the system.
Model helps make templates for constructing the system.
Model helps document the system.
Question: What are the different views that are considered when building an object-oriented software system?
Answer: Normally there are 5 views.
Use Case view - This view exposes the requirements of a system.
Design View - Capturing the vocabulary.
Process View - modeling the distribution of the systems processes and threads.
Implementation view - addressing the physical implementation of the system.
Deployment view - focus on the modeling the components required for deploying the system.
Question:What are the major three types of modeling used? Answer:
The 3 Major types of modeling are
architectural,
behavioral, and
structural.
Question:Name 9 modeling diagrams that are frequently used? Answer:
9 Modeling diagrams that are commonly used are
Use case diagram
Class Diagram
Object Diagram
Sequence Diagram
statechart Diagram
Collaboration Diagram
Activity Diagram
Component diagram
Deployment Diagram.
Question:How would you define Architecture? Answer:
Architecture is not only taking care of the structural and behavioral
aspect of a software system but also taking into account the software
usage, functionality, performance, reuse, economic and technology
constraints.
Question:What is SDLC (Software Development Life Cycle)? Answer: SDLC is a system including processes that are
Use case driven,
Architecture centric,
Iterative, and
Incremental.
What is the Life Cycle divided into?
Answer:
This Life cycle is divided into phases.
Each Phase is a time span between two milestones.
The milestones are
Inception,
Elaboration,
Construction, and
Transition.
What are the Process Workflows that evolve through these phases?
Answer:
The Process Workflows that evolve through these phases are
Business Modeling,
Requirement gathering,
Analysis and Design,
Implementation,
Testing,
Deployment.
Supporting Workflows are Configuration, change management, and Project management.
Question:What are Relationships? Answer: There are different kinds of relationships:
Dependencies,
Generalization, and
Association.
Dependencies are relationships between two entities.
A change in specification of one thing may affect another thing.
Most commonly it is used to show that one class uses another class as an argument in the signature of the operation.
Generalization is relationships specified in the class subclass scenario, it is shown when one entity inherits from other.
Associations are structural relationships that are:
a room has walls,
Person works for a company.
Aggregation is a type of association where there is a has a relationship.
As in the following examples: A room has walls, or if there are
two classes room and walls then the relation ship is called a
association and further defined as an aggregation.
Question:How are the diagrams divided?
Answer: The nine diagrams are divided into static diagrams and dynamic diagrams.
Question:Static Diagrams (Also called Structural Diagram):
Answer:
The following diagrams are static diagrams.
Class diagram,
Object diagram,
Component Diagram,
Deployment diagram.
Question:Dynamic Diagrams (Also called Behavioral Diagrams): Answer:
The following diagrams are dynamic diagrams.
Use Case Diagram,
Sequence Diagram,
Collaboration Diagram,
Activity diagram,
Statechart diagram.
Question:What are Messages? Answer:
A message is the specification of a communication, when a message is passed that results in action that is in turn an executable statement.
Question:What is an Use Case? Answer:
A use casespecifies the behavior of a system or a part of a system.
Use cases are used to capture the behavior that need to be developed.
It involves the interaction of actors and the system.
What is UML?
UML is Unified Modeling Language. It is a
graphical language for visualizing specifying constructing and
documenting the artifacts of the system. It allows you to create a blue
print of all the aspects of the system, before actually physically
implementing the system.
What is modeling? What are the advantages of creating a model?
Modeling
is a proven and well-accepted engineering technique which helps build a
model. Model is a simplification of reality; it is a blueprint of the
actual system that needs to be built. Model helps to visualize the
system. Model helps to specify the structural and behavior of the
system. Model helps make templates for constructing the system. Model
helps document the system.
What are the different views that are considered when building an object-oriented software system?
Normally there are 5 views.
Use Case view - This view exposes the requirements of a system.
Design View - Capturing the vocabulary.
Process View - modeling the distribution of the systems processes and threads.
Implementation view - addressing the physical implementation of the system.
Deployment view - focus on the modeling the components required for deploying the system.
What are diagrams?
Diagrams are graphical representation of a set of elements most often shown made of things and associations.
What are the major three types of modeling used?
Major three types of modeling are structural, behavioral, and architectural.
Mention the different kinds of modeling diagrams used?
Following modeling diagrams are commonly used.
Use case diagram
Class Diagram
Object Diagram
Sequence Diagram
State chart Diagram
Collaboration Diagram
Activity Diagram
Component diagram
Deployment Diagram
What is Architecture?
Architecture
is not only taking care of the structural and behavioral aspect of a
software system but also taking into account the software usage,
functionality, performance, reuse, economic and technology constraints.
What is SDLC?
SDLC
is Software Development Life Cycle. SDLC of a system included processes
that are Use case driven, Architecture centric and Iterative and
Incremental. This Life cycle is divided into phases. Phase is a time
span between two milestones. The milestones are Inception, Elaboration,
Construction, and Transition. Process Workflows that evolve through
these phase are Business Modeling, Requirement gathering, Analysis and
Design, Implementation, Testing, Deployment. Supporting Workflows are
Configuration and change management, Project management.
What are Relationships?
There are different kinds of relationships:
Dependencies: Dependencies
are relations ships between two entities that that a change in
specification of one thing may affect another thing. Most commonly it is
used to show that one class uses another class as an argument in the
signature of the operation.
Generalization: Generalization is
relationships specified in the class subclass scenario, it is shown when
one entity inherits from other.
Association: Associations are structural relationships i.e. a room has walls, Person works for a company.
Aggregation: Aggregation
is the typical whole/part relationship. This is exactly the same as an
association with the exception that instances cannot have cyclic
aggregation relationships (i.e. a part cannot contain its whole).
Composition:
Composition is exactly like Aggregation except that the lifetime of the
'part' is controlled by the 'whole'. This control may be direct or
transitive. That is, the 'whole' may take direct responsibility for
creating or destroying the 'part', or it may accept an already created
part, and later pass it on to some other whole that assumes
responsibility for it.
How are the diagrams divided?
The nine diagrams are divided into static diagrams and dynamic diagrams.
Static Diagrams (Also called Structural Diagram): Class diagram, Object diagram, Component Diagram, Deployment diagram.
Dynamic
Diagrams (Also called Behavioral Diagrams): Use Case Diagram, Sequence
Diagram, Collaboration Diagram, Activity diagram, Statechart diagram.
What are Messages?
A
message is the specification of a communication, when a message is
passed that results in action that is in turn an executable statement.
What is an Use Case?
A
use case specifies the behavior of a system or a part of a system, óse
cases are used to capture the behavior that need to be developed. It
involves the interaction of actors and the system.
Can you explain ‘Extend’ and ‘Include’ in use cases?
‘Extend’
and ‘Include’ define relationships between use cases. Below figure
‘Extend and Include’ shows how these two fundamentals are implemented in
a project. The below use case represents a system which is used to
maintain customer. When a customer is added successfully it should send
an email to the admin saying that a new customer is added. Only admin
have rights to modify the customer. First lets define extend and include
and then see how the same fits in this use case scenario.
Include:
Include relationship represents an invocation of one use case by the
other. If you think from the coding perspective its like one function
been called by the other function.
Extend: This relationship
signifies that the extending use case will work exactly like the base
use case only that some new steps will inserted in the extended use
case.
How do we represent private, public and protected in class diagrams?
In
order to represent visibility for properties and methods in class
diagram we need to place symbols next to each property and method as
shown in figure ‘Private, Public and Protected’. ‘+’ indicates that it’s
public properties/methods. ‘-‘indicates private properties which means
it can not be accessed outside the class. ‘#’ indicate protected/friend
properties. Protected properties can only be seen within the component
and not outside the component.
Can you explain sequence diagrams?
Sequence
diagram shows interaction between objects over a specific period time.
The message flow is shown vertically in waterfall manner i.e. it starts
from the top and flows to the bottom. Dashed lines represent the
duration for which the object will be live. Horizontal rectangles on the
dashed lines represent activation of the object. Messages sent from a
object is represented by dark arrow and dark arrow head. Return message
are represented by dotted arrow.
Can you explain primary and secondary actors?
Actors
are further classified in to two types primary and secondary actors.
Primary actors are the users who are the active participants and they
initiate the user case, while secondary actors are those who only
passively participate in the use case.
Can you explain use case diagrams?
Use
case diagram answers what system does from the user point of view. Use
case answer ‘What will the system do?’. Use cases are mainly used in
requirement document to depict clarity regarding a system. There are
three important parts in a use case scenario, actor and use case.
Scenario: A scenario is a sequence of events which happen when a user interacts with the system.
Actor: Actor is the who of the system, in other words the end user.
Use
Case: Use case is task or the goal performed by the end user. Below
figure ‘Use Case’ shows a simple scenario with ‘Actor’ and a ‘Use Case’.
Scenario represents an accountant entering accounts data in the system.
As use case’s represent action performed they are normally represented
by strong verbs.
Actor’s are represented by simple stick man and use case by oval shape.
Can you explain aggregation and composition in class diagrams?
In this Association there are two types mainly Aggregation Association and Composition Association.
Aggregation
Association signifies that the child objects can exist without the
Aggregated Object. Composition on the other hand represents a strict
"has a" relationship wherein child objects are tightly bound to the
parent class and life of its instance depends upon lifetime of top level
class instance. For example say we have three classes University
class, Department class and the Professor Class. The Department cannot
exist without university which means that if University is closed the
Department will also be closed. In other words lifetime of the
Department depend on the lifetime of University. This is an example of
composition. On the other hand instances of Professor class can continue
to exist even if a Department is shutdown representing and aggregation
association with Department class.
Note: The filled diamond represents the composition and the empty diamond represents the aggregation.
JDK follows several design principle like Factory Pattern in BorderFactory class, Singleton pattern in Runtime class, Decorator pattern on various java.io classes.
1) Explain what is Maven? How does it work?
Maven
is a project management tool. It provides the developer a complete
build lifecycle framework. On executing Maven commands, it will look for
POM file in Maven; it will run the command on the resources described
in the POM. 2) List out what are the aspects does Maven Manages?
Maven handles following activities of a developer
• Build
• Documentation
• Reporting
• Dependencies
• SCMs
• Releases
• Distribution
• Mailing list 3) Mention the three build lifecycle of Maven?
• Clean: Cleans up artifacts that are created by prior builds
• Default (build): Used to create the application
• Site: For the project generates site documentation 4) Explain what is POM?
In
Maven, POM (Project Object Model) is the fundamental unit of work. It
is an XML file which holds the information about the project and
configuration details used to build a project by Maven. 5) Explain what is Maven artifact?
Usually
an artifact is a JAR file which gets arrayed to a Maven repository. One
or more artifacts a maven build produces such as compiled JAR and a
sources JAR.
Each artifact includes a group ID, an artifact ID and a version string. 6) Explain what is Maven Repository? What are their types?
A
Maven repository is a location where all the project jars, library
jars, plugins or any other particular project related artifacts are
stored and can be easily used by Maven.
Their types are local, central and remote 7) Why Maven Plugins are used?
Maven plugins are used to
• Create a jar file
• Create war file
• Compile code files
• Unit testing of code
• Documenting projects
• Reporting 8) List out the dependency scope in Maven?
The various dependency scope used in Maven are:
• Compile: It is the default scope, and it indicates what dependency is available in the classpath of the project
• Provided: It indicates that the dependency is provided by JDK or web server or container at runtime
• Runtime: This tells that the dependency is not needed for compilation but is required during execution
• Test: It says dependency is available only for the test compilation and execution phases
• System: It indicates you have to provide the system path
• Import: This indicates that the identified or specified POM should be replaced with the dependencies in that POM’s section 9) Mention how profiles are specified in Maven?
Profiles are specified in Maven by using a subset of the elements existing in the POM itself. 10) Explain how you can exclude dependency?
By using the exclusion element, dependency can be excluded 11) Mention the difference between Apache Ant and Maven?
Apache Ant Maven
• Ant is a toolbox – Maven is a framework
• Ant does not have formal conventions like project directory structure – Maven has conventions
• Ant is procedural; you have to tell to compile, copy and compress –
Maven is declarative ( information on what to make & how to build)
• Ant does not have lifecycle; you have to add sequence of tasks manually – Maven has a lifecycle
• Ant scripts are not reusable – Maven plugins are reusable 12) In Maven what are the two setting files called and what are their location?
In Maven, the setting files are called settings.xml, and the two setting files are located at
• Maven installation directory: $M2_Home/conf/settings.xml
• User’s home directory: ${ user.home }/ .m2 / settings.xml 13) List out what are the build phases in Maven?
Build phases in Maven are
• Validate
• Compile
• Test
• Package
• Install
• Deploy 14) List out the build, source and test source directory for POM in Maven?
• Build = Target
• Source = src/main/java
• Test = src/main/test 15) Where do you find the class files when you compile a Maven project?
You will find the class files ${basedir}/target/classes/. 16) Explain what would the “jar: jar” goal do?
jar:
jar will not recompile sources; it will imply just create a JAR from
the target/classes directory considering that everything else has been
done 17) List out what are the Maven’s order of inheritance?
The maven’s order of inheritance is
• Parent Pom
• Project Pom
• Settings
• CLI parameters 18) For POM what are the minimum required elements?
The minimum required elements for POM are project root, modelVersion, groupID, artifactID and version 19) Explain how you can produce execution debug output or error messages?
To produce execution debug output you could call Maven with X parameter or e parameter 20) Explain how to run test classes in Maven?
To
run test classes in Maven, you need surefire plugin, check and
configure your settings in setting.xml and pom.xml for a property named
“test.”
